[PATCH 04/18] OMAPDSS: panel-sony-acx565akm: Export OF module alias information
The SPI core always reports the MODALIAS uevent as "spi:"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: SPI id table or OF match table).
So drivers needs to export the SPI id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
But this means that OF-only drivers needs to have both OF and SPI id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same SPI device name for example.
To avoid the above, the SPI core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
index 90cbc4c3406c..c581231c74a5 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
@@ -898,6 +898,7 @@ static const struct of_device_id acx565akm_of_match[] = {
{ .compatible = "omapdss,sony,acx565akm", },
{},
};
+MODULE_DEVICE_TABLE(of, acx565akm_of_match);
static struct spi_driver acx565akm_driver = {
.driver = {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] Export SPI and OF module aliases in missing drivers
Hello, Short version: This patch series is the SPI equivalent of the I2C one posted before [0]. This series add the missing MODULE_DEVICE_TABLE() for OF and SPI tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: The SPI core always reports the MODALIAS uevent as "spi:" regardless of the mechanism that was used to register the device (i.e: OF or board code) and the table that is used later to match the driver with the device (i.e: SPI id table or OF match table). But this means that OF-only drivers needs to have both OF and SPI id tables that have to be kept in sync and also the device node's compatible manufacturer prefix is stripped when reporting the MODALIAS. Which can lead to issues if two vendors use the same SPI device name for example. Also, there are many SPI drivers whose module auto-loading is not working because of this fact that the SPI core always reports the MODALIAS as spi: and many developers didn't expect this since is not how other subsystems behave. I've identified SPI drivers with 3 types of different issues: a) Those that have an spi_table but are not exported. The match works if the driver is built-in but since the ID table is not exported, module auto-load won't work. b) Those that have a of_table but are not exported. This is currently not an issue since even when the of_table is used to match the dev with the driver, an OF modalias is not reported by the SPI core. But if the SPI core is changed to report the MODALIAS of the form of:N*T*C as it's made by other subsystems, then module auto-load will break for these drivers. c) Those that don't have an of_table but should since are OF drivers with DT bindings doc for them. Since the SPI core does not report a OF modalias and since spi_match_device() fallbacks to match the device part of the compatible string with the SPI device ID table, many OF drivers don't have an of_table to match. After all having a SPI device ID table is mandatory so it works without a of_table. So, in order to not make mandatory to have a SPI device ID table, all these three kind of issues have to be addressed. This series does that. I split the changes so the patches in this series are independent and can be picked individually by subsystem maintainers. Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches Patch #18 changes the logic of spi_uevent() to report an OF modalias if the device was registered using OF. But this patch is included in the series only as an RFC for illustration purposes since changing that without first applying all the other patches in this series, will break module autoloading for the drivers of devices registered using OF but that lacks an of_match_table. I'll repost patch #18 once all the patches in this series have landed. [0]: https://lkml.org/lkml/2015/7/30/519 Best regards, Javier Javier Martinez Canillas (18): iio: Export SPI module alias information in missing drivers staging: iio: hmc5843: Export missing SPI module alias information mtd: dataflash: Export OF module alias information OMAPDSS: panel-sony-acx565akm: Export OF module alias information mmc: mmc_spi: Export OF module alias information staging: mt29f_spinand: Export OF module alias information net: ks8851: Export OF module alias information [media] s5c73m3: Export OF module alias information mfd: cros_ec: spi: Add OF match table iio: dac: ad7303: Add OF match table iio: adc: max1027: Set struct spi_driver .of_match_table mfd: stmpe: Add OF match table iio: adc: mcp320x: Set struct spi_driver .of_match_table iio: as3935: Add OF match table iio: adc128s052: Add OF match table iio: frequency: adf4350: Add OF match table NFC: trf7970a: Add OF match table spi: (RFC, don't apply) report OF style modalias when probing using DT drivers/iio/adc/max1027.c | 1 + drivers/iio/adc/mcp320x.c | 1 + drivers/iio/adc/ti-adc128s052.c | 8 drivers/iio/amplifiers/ad8366.c | 1 + drivers/iio/dac/ad7303.c| 7 +++ drivers/iio/frequency/adf4350.c | 9 + drivers/iio/proximity/as3935.c | 7 +++ drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 + drivers/mfd/cros_ec_spi.c | 7 +++ drivers/mfd/stmpe-spi.c | 13 + drivers/mmc/host/mmc_spi.c | 1 + drivers/mtd/devices/mtd_dataflash.c | 1 + drivers/net/ethernet/micrel/ks8851.c| 1 + drivers/nfc/trf7970a.c | 7 +++ drivers/spi/spi.c | 8 drivers/s
Re: [PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
On 10/07/15 09:37, Krzysztof Kozlowski wrote: > Hi, > > > The i2c drivers also do not have to set 'owner' field because > i2c_register_driver() will do it instead. > > 'owner' is removed from i2c drivers, which I was able to compile > with allyesconfig (arm, arm64, i386, x86_64, ppc64). > Only compile-tested. > > The coccinelle script which generated the patch was sent here: > http://www.spinics.net/lists/kernel/msg2029903.html > > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (2): > video: fbdev: Drop owner assignment from i2c_driver > video: fbdev: Drop owner assignment from platform_driver > > drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 1 - > drivers/video/fbdev/ssd1307fb.c | 1 - > 2 files changed, 2 deletions(-) > Thanks, queued for 4.3. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] spi: ti-qspi: use 128 bit transfer mode for writing to flash
TI QSPI has four 32 bit data regsiters which can be used to transfer 16
bytes of data at once. The register group QSPI_SPI_DATA_REG_3,
QSPI_SPI_DATA_REG_2, QSPI_SPI_DATA_REG_1 and QSPI_SPI_DATA_REG is
treated as a single 128-bit word for shifting data in and out. The bit
at QSPI_SPI_DATA_REG_3[31] position is the first bit to be shifted out
in case of 128 bit transfer mode. Therefore the first byte to be written
to flash should be at QSPI_SPI_DATA_REG_3[31-25] position.
Instead of writing 1 byte at a time when interacting with spi-nor flash,
make use of all the four registers so that 16 bytes can be transferred
in one go. This reduces number of register writes and Word Complete
interrupts for a given transfer message size, thereby increasing the
write performance.
Without this patch the raw flash write speed is ~100KB/s, with this
patch the write speed increases to ~400 kB/s on DRA74 EVM.
Signed-off-by: Vignesh R
---
drivers/spi/spi-ti-qspi.c | 34 ++
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 45844a227c5e..f4cea6834fad 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -96,6 +96,8 @@ struct ti_qspi {
#define QSPI_INVAL (4 << 16)
#define QSPI_WC_CMD_INT_EN (1 << 14)
#define QSPI_FLEN(n) ((n - 1) << 0)
+#define QSPI_WLEN_MAX_BITS 128
+#define QSPI_WLEN_MAX_BYTES16
/* STATUS REGISTER */
#define BUSY 0x01
@@ -224,14 +226,16 @@ static inline u32 qspi_is_busy(struct ti_qspi *qspi)
static int qspi_write_msg(struct ti_qspi *qspi, struct spi_transfer *t)
{
- int wlen, count;
+ int wlen, count, xfer_len;
unsigned int cmd;
const u8 *txbuf;
+ u32 data;
txbuf = t->tx_buf;
cmd = qspi->cmd | QSPI_WR_SNGL;
count = t->len;
wlen = t->bits_per_word >> 3; /* in bytes */
+ xfer_len = wlen;
while (count) {
if (qspi_is_busy(qspi))
@@ -241,7 +245,29 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
case 1:
dev_dbg(qspi->dev, "tx cmd %08x dc %08x data %02x\n",
cmd, qspi->dc, *txbuf);
- writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
+ if (count >= QSPI_WLEN_MAX_BYTES) {
+ u32 *txp = (u32 *)txbuf;
+
+ data = cpu_to_be32(*txp++);
+ writel(data, qspi->base +
+ QSPI_SPI_DATA_REG_3);
+ data = cpu_to_be32(*txp++);
+ writel(data, qspi->base +
+ QSPI_SPI_DATA_REG_2);
+ data = cpu_to_be32(*txp++);
+ writel(data, qspi->base +
+ QSPI_SPI_DATA_REG_1);
+ data = cpu_to_be32(*txp++);
+ writel(data, qspi->base +
+ QSPI_SPI_DATA_REG);
+ xfer_len = QSPI_WLEN_MAX_BYTES;
+ cmd |= QSPI_WLEN(QSPI_WLEN_MAX_BITS);
+ } else {
+ writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
+ cmd = qspi->cmd | QSPI_WR_SNGL;
+ xfer_len = wlen;
+ cmd |= QSPI_WLEN(wlen);
+ }
break;
case 2:
dev_dbg(qspi->dev, "tx cmd %08x dc %08x data %04x\n",
@@ -261,8 +287,8 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
dev_err(qspi->dev, "write timed out\n");
return -ETIMEDOUT;
}
- txbuf += wlen;
- count -= wlen;
+ txbuf += xfer_len;
+ count -= xfer_len;
}
return 0;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/16] omap_hsmmc: regulator usage cleanup and fixes
Hi, On Monday 03 August 2015 05:56 PM, Kishon Vijay Abraham I wrote: > Changes from v1: > *) return on -EPROBE_DEFER and other fatal errors. (Don't return only >if the return value is -ENODEV) > *) Remove the beagle x15 dts patch. It can be part of a different >series. > *) Avoid using regulator_is_enabled for vqmmc since if the regulator >is shared and the other users are not using regulator_is_enabled >then there can be unbalanced regulator_enable/regulator_disable > > This patch series does the following > *) Uses devm_regulator_get_optional() for vmmc and then removes the >CONFIG_REGULATOR check altogether. > *) return on -EPROBE_DEFER and any other fatal errors > *) enable/disable vmmc_aux regulator based on prior state > > I've pushed this patch series to > git://git.ti.com/linux-phy/linux-phy.git mmc_regulator_cleanup_fixes_v2 > > Please note the branch also has the pbias fixes [1] & [2]. > [1] -> https://lkml.org/lkml/2015/7/27/358 > [2] -> https://lkml.org/lkml/2015/7/27/391 > > This series is in preparation for implementing the voltage switch > sequence so that UHS cards can be supported. > > Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, > Beaglebone black, OMAP5 uEVM and OMAP4 PANDA. I have now done read/write test in omap3 beagle-xm with this series! Thanks Kishon > > Kishon Vijay Abraham I (15): > mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc > mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get > mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get() > mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator > mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc > mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage > mmc: host: omap_hsmmc: return error if any of the regulator APIs fail > mmc: host: omap_hsmmc: add separate functions for enable/disable > supply > mmc: host: omap_hsmmc: add separate function to set pbias > mmc: host: omap_hsmmc: avoid pbias regulator enable on power off > mmc: host: omap_hsmmc: don't use ->set_power to set initial regulator > state > mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on > previous state > mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status > mmc: host: omap_hsmmc: use ios->vdd for setting vmmc voltage > mmc: host: omap_hsmmc: remove CONFIG_REGULATOR check > > Roger Quadros (1): > mmc: host: omap_hsmmc: use "mmc_of_parse_voltage" to get ocr_avail > > .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |2 + > drivers/mmc/host/omap_hsmmc.c | 340 > +--- > 2 files changed, 224 insertions(+), 118 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
Hi,
On Fri, Jul 31, 2015 at 04:00:13PM +0200, Robert Baldyga wrote:
> So far it was necessary for usb functions to set ep->driver_data in
> endpoint obtained from autoconfig to non-null value, to indicate that
> endpoint is claimed by function (in autoconfig it was checked if endpoint
> has set this field to non-null value, and if it has, it was assumed that
> it is claimed). It could cause bugs because if some function doesn't
> set this field autoconfig could return the same endpoint more than one
> time.
>
> To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
> and encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
> and usb_ep_autoconfig_reset(), so now usb functions don't need to perform
> any additional actions to mark endpoint obtained from autoconfig as claimed.
>
> Signed-off-by: Robert Baldyga
just letting you know that this regresses all gadget drivers making them
try to disable previously disabled endpoints and enable previously
enabled endpoints.
I have a possible fix (see below) but then it shows a problem on the
host side when using with g_zero (see further below):
commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
Author: Felipe Balbi
Date: Wed Aug 19 18:05:27 2015 -0500
usb: gadget: fix ep->claimed lifetime
In order to fix a regression introduced by commit
cc476b42a39d ("usb: gadget: encapsulate endpoint
claiming mechanism") we have to introduce a simple
helper to check if a particular is enabled or not.
After that, we need to move ep->claimed lifetime to
usb_ep_enable() and usb_ep_disable() since those
are the only functions which actually enable and
disable endpoints.
A follow-up patch will come to drop all driver_data
checks from function drivers, since those are, now,
pointless.
Fixes: cc476b42a39d ("usb: gadget: encapsulate endpoint
claiming mechanism")
Cc: Robert Baldyga
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 978435a51038..ad45070cd76f 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -126,7 +126,6 @@ found_ep:
ep->address = desc->bEndpointAddress;
ep->desc = NULL;
ep->comp_desc = NULL;
- ep->claimed = true;
return ep;
}
EXPORT_SYMBOL_GPL(usb_ep_autoconfig_ss);
@@ -182,11 +181,6 @@ EXPORT_SYMBOL_GPL(usb_ep_autoconfig);
*/
void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
{
- struct usb_ep *ep;
-
- list_for_each_entry (ep, &gadget->ep_list, ep_list) {
- ep->claimed = false;
- }
gadget->in_epnum = 0;
gadget->out_epnum = 0;
}
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index c14a69b36d27..9b3d60c1cf9f 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -243,6 +243,22 @@ static inline void usb_ep_set_maxpacket_limit(struct
usb_ep *ep,
}
/**
+ * usb_ep_enabled - is endpoint enabled ?
+ * @ep: the endpoint being checked. may not be the endpoint named "ep0".
+ *
+ * Whenever a function driver wants to check if a particular endpoint is
+ * enabled or not, it must check using this helper function. This will
+ * encapsulate details about how the endpoint is checked, saving the function
+ * driver from using private methods for doing so.
+ *
+ * return true if endpoint is enabled, false otherwise.
+ */
+static inline bool usb_ep_enabled(struct usb_ep *ep)
+{
+ return ep->claimed;
+}
+
+/**
* usb_ep_enable - configure endpoint, making it usable
* @ep:the endpoint being configured. may not be the endpoint named "ep0".
* drivers discover endpoints through the ep_list of a usb_gadget.
@@ -264,7 +280,18 @@ static inline void usb_ep_set_maxpacket_limit(struct
usb_ep *ep,
*/
static inline int usb_ep_enable(struct usb_ep *ep)
{
- return ep->ops->enable(ep, ep->desc);
+ int ret;
+
+ if (usb_ep_enabled(ep))
+ return 0;
+
+ ret = ep->ops->enable(ep, ep->desc);
+ if (ret)
+ return ret;
+
+ ep->claimed = true;
+
+ return 0;
}
/**
@@ -281,7 +308,18 @@ static inline int usb_ep_enable(struct usb_ep *ep)
*/
static inline int usb_ep_disable(struct usb_ep *ep)
{
- return ep->ops->disable(ep);
+ int ret;
+
+ if (!usb_ep_enabled(ep))
+ return 0;
+
+ ret = ep->ops->disable(ep);
+ if (ret)
+ return ret;
+
+ ep->claimed = false;
+
+ return 0;
}
/**
[ 73.290345] WARNING: CPU: 0 PID: 300 at lib/kobject.c:240
kobject_add_internal+0x25c/0x2d8()
[ 73.299172] kobject_add_internal failed for ep_81 with -EEXIST, don't try to
register things with the same name in the same directory.
[ 73.311825] Modules linked in: usbtest usb_f_ss_lb g_zero libcomposite
xhci_plat_hcd xhci_hcd usbcore joydev dwc3 udc_core usb_common m25p80 evdev
spi_nor omapfb
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
Hi Felipe,
On 08/20/2015 05:35 PM, Felipe Balbi wrote:
[...]
just letting you know that this regresses all gadget drivers making them
try to disable previously disabled endpoints and enable previously
enabled endpoints.
I have a possible fix (see below) but then it shows a problem on the
host side when using with g_zero (see further below):
commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
Author: Felipe Balbi
Date: Wed Aug 19 18:05:27 2015 -0500
usb: gadget: fix ep->claimed lifetime
In order to fix a regression introduced by commit
cc476b42a39d ("usb: gadget: encapsulate endpoint
claiming mechanism") we have to introduce a simple
helper to check if a particular is enabled or not.
After that, we need to move ep->claimed lifetime to
usb_ep_enable() and usb_ep_disable() since those
are the only functions which actually enable and
disable endpoints.
A follow-up patch will come to drop all driver_data
checks from function drivers, since those are, now,
pointless.
Fixes: cc476b42a39d ("usb: gadget: encapsulate endpoint
claiming mechanism")
Cc: Robert Baldyga
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 978435a51038..ad45070cd76f 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -126,7 +126,6 @@ found_ep:
ep->address = desc->bEndpointAddress;
ep->desc = NULL;
ep->comp_desc = NULL;
- ep->claimed = true;
Removing this line causes autoconfig can return the same endpoint many
times. This probably causes problems with g_zero.
I will try to fix it ASAP.
Thanks,
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote:
> Hi Felipe,
>
> On 08/20/2015 05:35 PM, Felipe Balbi wrote:
> [...]
> >just letting you know that this regresses all gadget drivers making them
> >try to disable previously disabled endpoints and enable previously
> >enabled endpoints.
> >
> >I have a possible fix (see below) but then it shows a problem on the
> >host side when using with g_zero (see further below):
> >
> >commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
> >Author: Felipe Balbi
> >Date: Wed Aug 19 18:05:27 2015 -0500
> >
> > usb: gadget: fix ep->claimed lifetime
> >
> > In order to fix a regression introduced by commit
> > cc476b42a39d ("usb: gadget: encapsulate endpoint
> > claiming mechanism") we have to introduce a simple
> > helper to check if a particular is enabled or not.
> >
> > After that, we need to move ep->claimed lifetime to
> > usb_ep_enable() and usb_ep_disable() since those
> > are the only functions which actually enable and
> > disable endpoints.
> >
> > A follow-up patch will come to drop all driver_data
> > checks from function drivers, since those are, now,
> > pointless.
> >
> > Fixes: cc476b42a39d ("usb: gadget: encapsulate endpoint
> > claiming mechanism")
> > Cc: Robert Baldyga
> > Signed-off-by: Felipe Balbi
> >
> >diff --git a/drivers/usb/gadget/epautoconf.c
> >b/drivers/usb/gadget/epautoconf.c
> >index 978435a51038..ad45070cd76f 100644
> >--- a/drivers/usb/gadget/epautoconf.c
> >+++ b/drivers/usb/gadget/epautoconf.c
> >@@ -126,7 +126,6 @@ found_ep:
> > ep->address = desc->bEndpointAddress;
> > ep->desc = NULL;
> > ep->comp_desc = NULL;
> >-ep->claimed = true;
>
> Removing this line causes autoconfig can return the same endpoint many
> times. This probably causes problems with g_zero.
>
> I will try to fix it ASAP.
I was considering the same thing, but the lifetime of ->claimed doesn't
look correct to me either way. Note that once the flag is enabled, it
won't get disabled by most gadget drivers.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On 08/20/2015 06:48 PM, Felipe Balbi wrote:
On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote:
Hi Felipe,
On 08/20/2015 05:35 PM, Felipe Balbi wrote:
[...]
just letting you know that this regresses all gadget drivers making them
try to disable previously disabled endpoints and enable previously
enabled endpoints.
I have a possible fix (see below) but then it shows a problem on the
host side when using with g_zero (see further below):
commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
Author: Felipe Balbi
Date: Wed Aug 19 18:05:27 2015 -0500
usb: gadget: fix ep->claimed lifetime
In order to fix a regression introduced by commit
cc476b42a39d ("usb: gadget: encapsulate endpoint
claiming mechanism") we have to introduce a simple
helper to check if a particular is enabled or not.
After that, we need to move ep->claimed lifetime to
usb_ep_enable() and usb_ep_disable() since those
are the only functions which actually enable and
disable endpoints.
A follow-up patch will come to drop all driver_data
checks from function drivers, since those are, now,
pointless.
Fixes: cc476b42a39d ("usb: gadget: encapsulate endpoint
claiming mechanism")
Cc: Robert Baldyga
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 978435a51038..ad45070cd76f 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -126,7 +126,6 @@ found_ep:
ep->address = desc->bEndpointAddress;
ep->desc = NULL;
ep->comp_desc = NULL;
- ep->claimed = true;
Removing this line causes autoconfig can return the same endpoint many
times. This probably causes problems with g_zero.
I will try to fix it ASAP.
I was considering the same thing, but the lifetime of ->claimed doesn't
look correct to me either way. Note that once the flag is enabled, it
won't get disabled by most gadget drivers.
And it should not be. This flag is indicator, that endpoint is used by
some function. It should be set once by usb_ep_autoconfig() and cleared
by usb_ep_autoconfig_reset().
I wonder what is reason of this enable/disable regression. Maybe the
problem is that we don't set ep->driver_data to NULL in
usb_ep_autoconfig_reset() (so far it was done). Does this problem occur
while gadget is binded to UDC for the first time, or at any next time?
Unfortunately at this moment I don't have access to my hardware, so it
will take a moment before I will setup some testing environment.
Thanks,
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
On Thu, Aug 20, 2015 at 11:21:06AM +0530, Kishon Vijay Abraham I wrote: > On Wednesday 19 August 2015 11:41 PM, Mark Brown wrote: > > On Tue, Aug 18, 2015 at 11:23:54AM +0530, Kishon Vijay Abraham I wrote: Please fix your mail client to word wrap within paragraphs. > >> platform_get_resource can be used if we need the absolute address but here > >> we > >> need only the offset. > > So substract this address from the start of the resource to get the > That would mean from the offset (provided in dt) get the absolute address and > then again from the absolute address get the offset. Sure, that's how the Linux APIs work right now and why I'm suggesting you might want a wrapper. > > offset? Or provide a wrapper function in the resource code which does > Why not use 'of_get_address' which does the same thing? Moreover it's not a > resource we are dealing with here. It's a resource only for the syscon driver. This is how the OF description you've done is intended to be parsed and hence is interpreted by the generic code, it's just a detail of the syscon implementation that you need to translate it into an offset. > > that. What you're saying above is pretty much "this happens to work" > > but my concern is that the solution that happens to work isn't really > > what we want to do. > Not just makes this work, this is also the most reasonable solution available > IMHO. In general moving to a lower level inteface is not usually a step forward. As far as I can tell the driver already has all the information it needs from the more generic APIs, it's just not interpreting it in the way that the APIs it's trying to use wants. It just needs to fix the way it interprets the data it's passing through. > The most ideal way would have been to use something like what Grygorii > mentioned to use syscon = <&scm_conf 0xe00> and then use the phandle to get > the > offset. But then with this we'll be breaking older dtbs. There is no need to break older DTs, that would clearly be a bad idea. signature.asc Description: Digital signature
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
Hi,
On Thu, Aug 20, 2015 at 07:16:48PM +0200, Robert Baldyga wrote:
> On 08/20/2015 06:48 PM, Felipe Balbi wrote:
> >On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote:
> >>Hi Felipe,
> >>
> >>On 08/20/2015 05:35 PM, Felipe Balbi wrote:
> >>[...]
> >>>just letting you know that this regresses all gadget drivers making them
> >>>try to disable previously disabled endpoints and enable previously
> >>>enabled endpoints.
> >>>
> >>>I have a possible fix (see below) but then it shows a problem on the
> >>>host side when using with g_zero (see further below):
> >>>
> >>>commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
> >>>Author: Felipe Balbi
> >>>Date: Wed Aug 19 18:05:27 2015 -0500
> >>>
> >>> usb: gadget: fix ep->claimed lifetime
> >>>
> >>> In order to fix a regression introduced by commit
> >>> cc476b42a39d ("usb: gadget: encapsulate endpoint
> >>> claiming mechanism") we have to introduce a simple
> >>> helper to check if a particular is enabled or not.
> >>>
> >>> After that, we need to move ep->claimed lifetime to
> >>> usb_ep_enable() and usb_ep_disable() since those
> >>> are the only functions which actually enable and
> >>> disable endpoints.
> >>>
> >>> A follow-up patch will come to drop all driver_data
> >>> checks from function drivers, since those are, now,
> >>> pointless.
> >>>
> >>> Fixes: cc476b42a39d ("usb: gadget: encapsulate endpoint
> >>> claiming mechanism")
> >>> Cc: Robert Baldyga
> >>> Signed-off-by: Felipe Balbi
> >>>
> >>>diff --git a/drivers/usb/gadget/epautoconf.c
> >>>b/drivers/usb/gadget/epautoconf.c
> >>>index 978435a51038..ad45070cd76f 100644
> >>>--- a/drivers/usb/gadget/epautoconf.c
> >>>+++ b/drivers/usb/gadget/epautoconf.c
> >>>@@ -126,7 +126,6 @@ found_ep:
> >>> ep->address = desc->bEndpointAddress;
> >>> ep->desc = NULL;
> >>> ep->comp_desc = NULL;
> >>>- ep->claimed = true;
> >>
> >>Removing this line causes autoconfig can return the same endpoint many
> >>times. This probably causes problems with g_zero.
> >>
> >>I will try to fix it ASAP.
> >
> >I was considering the same thing, but the lifetime of ->claimed doesn't
> >look correct to me either way. Note that once the flag is enabled, it
> >won't get disabled by most gadget drivers.
>
> And it should not be. This flag is indicator, that endpoint is used by some
> function. It should be set once by usb_ep_autoconfig() and cleared by
> usb_ep_autoconfig_reset().
have you considered switching interfaces and/or alternate settings ?
> I wonder what is reason of this enable/disable regression. Maybe the problem
> is that we don't set ep->driver_data to NULL in usb_ep_autoconfig_reset()
> (so far it was done). Does this problem occur while gadget is binded to UDC
> for the first time, or at any next time? Unfortunately at this moment I
> don't have access to my hardware, so it will take a moment before I will
> setup some testing environment.
yeah, that's okay. We've got time.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] spi: ti-qspi: use 128 bit transfer mode for writing to flash
On Thu, Aug 20, 2015 at 04:00:59PM +0530, Vignesh R wrote:
> - writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
> + if (count >= QSPI_WLEN_MAX_BYTES) {
> + u32 *txp = (u32 *)txbuf;
> +
> + data = cpu_to_be32(*txp++);
> + writel(data, qspi->base +
> +QSPI_SPI_DATA_REG_3);
> + data = cpu_to_be32(*txp++);
> + writel(data, qspi->base +
> +QSPI_SPI_DATA_REG_2);
> + data = cpu_to_be32(*txp++);
> + writel(data, qspi->base +
> +QSPI_SPI_DATA_REG_1);
> + data = cpu_to_be32(*txp++);
> + writel(data, qspi->base +
> +QSPI_SPI_DATA_REG);
> + xfer_len = QSPI_WLEN_MAX_BYTES;
> + cmd |= QSPI_WLEN(QSPI_WLEN_MAX_BITS);
> + } else {
> + writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
> + cmd = qspi->cmd | QSPI_WR_SNGL;
> + xfer_len = wlen;
> + cmd |= QSPI_WLEN(wlen);
> + }
It's a bit sad that this isn't able to do a Duff's device type thing and
only kicks in for the full 128 bit FIFO size, it looks like it could do
any number of words.
signature.asc
Description: Digital signature
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On 8/20/2015 10:45 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Aug 20, 2015 at 07:16:48PM +0200, Robert Baldyga wrote:
>> On 08/20/2015 06:48 PM, Felipe Balbi wrote:
>>> On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote:
Hi Felipe,
On 08/20/2015 05:35 PM, Felipe Balbi wrote:
[...]
> just letting you know that this regresses all gadget drivers making them
> try to disable previously disabled endpoints and enable previously
> enabled endpoints.
>
> I have a possible fix (see below) but then it shows a problem on the
> host side when using with g_zero (see further below):
>
> commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
> Author: Felipe Balbi
> Date: Wed Aug 19 18:05:27 2015 -0500
>
> usb: gadget: fix ep->claimed lifetime
>
> In order to fix a regression introduced by commit
> cc476b42a39d ("usb: gadget: encapsulate endpoint
> claiming mechanism") we have to introduce a simple
> helper to check if a particular is enabled or not.
>
> After that, we need to move ep->claimed lifetime to
> usb_ep_enable() and usb_ep_disable() since those
> are the only functions which actually enable and
> disable endpoints.
>
> A follow-up patch will come to drop all driver_data
> checks from function drivers, since those are, now,
> pointless.
>
> Fixes: cc476b42a39d ("usb: gadget: encapsulate endpoint
> claiming mechanism")
> Cc: Robert Baldyga
> Signed-off-by: Felipe Balbi
>
> diff --git a/drivers/usb/gadget/epautoconf.c
> b/drivers/usb/gadget/epautoconf.c
> index 978435a51038..ad45070cd76f 100644
> --- a/drivers/usb/gadget/epautoconf.c
> +++ b/drivers/usb/gadget/epautoconf.c
> @@ -126,7 +126,6 @@ found_ep:
> ep->address = desc->bEndpointAddress;
> ep->desc = NULL;
> ep->comp_desc = NULL;
> - ep->claimed = true;
Removing this line causes autoconfig can return the same endpoint many
times. This probably causes problems with g_zero.
I will try to fix it ASAP.
>>>
>>> I was considering the same thing, but the lifetime of ->claimed doesn't
>>> look correct to me either way. Note that once the flag is enabled, it
>>> won't get disabled by most gadget drivers.
>>
>> And it should not be. This flag is indicator, that endpoint is used by some
>> function. It should be set once by usb_ep_autoconfig() and cleared by
>> usb_ep_autoconfig_reset().
And the 'claimed' flag should be used for the ep autoconfig
mechanism alone. We may want to reset it during the autoconfig
phase for multiple configs and alt-interfaces. So there should be
separate 'claimed' and 'enabled' flags.
>
> have you considered switching interfaces and/or alternate settings ?
We ran into similar issues before with this very scenario. Handling
of set_config(0 or N), in both addressed and configured states, and
set_interface requests.
John
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers
On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote: > Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches ^^^ I'm dying to know how this sentence ends :) > Patch #18 changes the logic of spi_uevent() to report an OF modalias if > the device was registered using OF. But this patch is included in the > series only as an RFC for illustration purposes since changing that > without first applying all the other patches in this series, will break > module autoloading for the drivers of devices registered using OF but > that lacks an of_match_table. I'll repost patch #18 once all the patches > in this series have landed. On a more productive note, the patches I've looked at look good to me. The missing aliases are a problem enough that should be fixed (i.e., part (b)). I'll leave the SPI framework changes to others to comment on. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers
Hello Brian, On 08/20/2015 11:11 PM, Brian Norris wrote: > On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote: >> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches > > ^^^ I'm dying to know how this sentence ends :) > Sigh, I did some last minute restructuring of the cover letter and seems I missed a sentence. I meant to said: "and patches #9 to #17 solves c)." >> Patch #18 changes the logic of spi_uevent() to report an OF modalias if >> the device was registered using OF. But this patch is included in the >> series only as an RFC for illustration purposes since changing that >> without first applying all the other patches in this series, will break >> module autoloading for the drivers of devices registered using OF but >> that lacks an of_match_table. I'll repost patch #18 once all the patches >> in this series have landed. > > On a more productive note, the patches I've looked at look good to me. > The missing aliases are a problem enough that should be fixed (i.e., > part (b)). I'll leave the SPI framework changes to others to comment on. > Great, thanks a lot for your feedback. > Brian > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
