Re: [PATCH v1 1/5] mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemes
Hi Pekon, On Mon, Jul 15, 2013 at 8:25 PM, Pekon Gupta wrote: > chip->ecc.correct() is used for detecting and correcting bit-flips during read > operations. In omap2-nand driver this is done usingt following functions: > > - omap_correct_data(): for H/W based HAM1_ECC schemes > (Un-Touched in current patch) > > - omap_elm_correct_data(): for H/W based BCHx_ECC scheme > Current implementation of this function is not scalable for newer ECC > schemes because: > - It depends on a specific byte-position in OOB area (reserved as > 0x00) > to differentiates between programmed-pages and erased-pages. > This reserved byte-position cannot be accomodated in all ECC > schemes. > - Current code is not scalable for future ECC schemes due to tweaks > for > BCH4_ECC and BCH8_ECC at multiple places. > - It checks for bit-flips in Erased-pages using check_erased_page(). > This is over-work, as sanity of Erased-page can be verified by just > comparing them to a pre-defined ECC-syndrome for all_0xFF data. This is correct if the erased page read back didn't have any bit flips. If erased page result in bit flips, then this method will end up in un-correctable error. Can you please confirm you taken care erased page bit flips in this modification? I think below discussion would help. https://lkml.org/lkml/2012/11/22/590 Thanks Avinash -- 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: v3.11-rc1 USB regressions
Hi Aaro,
On 16.07.2013 00:56, Aaro Koskinen wrote:
> Hi,
>
> I think USB tree introduced regressions in v3.11-rc1, at least for some
> OMAP devices using legacy boot.
Thanks for checking the tree so early.
> I have only bisected these; I have no
> idea what the real fixes are but the following reverts make Nokia OMAP2+
> boards again usable for kernel development work (they need working USB
> connection for interacting with the device):
>
> 1) USB peripheral mode (g_ether) is broken on Nokia N900, N950 and N9
>(USB_MUSB_OMAP2PLUS). To make it it work, I need to revert three
>commits:
>
> 09fc7d22b024692b2fe8a943b246de1af307132b
> usb: musb: fix incorrect usage of resource pointer
> (Reverting this fixes the g_ether probe failure "couldn't find
>an available UDC")
Can't say much about this one, but I'd like you to only keep this one
reverted and sort out the regressions in the musb core first.
> fe4cb0912f8e737f8e4b8b38b9e692f8062f5423
> usb: musb: gadget: remove hcd initialization
> (Reverting this fixes error "cdc_ether: probe of 4-1:1.0 failed
>with error -110" seen on the host side.)
Which role does your musb-based hardware have in this case, and which
MUSB_* config symbols do you set? You should have USB_MUSB_GADGET.
> 8b125df5b24cfb0ec7fa1971e343cc0badc1827d
> usb: musb: eliminate musb_to_hcd
> (Reverting this fixes compilation error cause by the previous
>revert.)
>
> 2) USB peripheral mode (g_ether) is broken also on Nokia N800 and N810
>(USB_MUSB_TUSB6010). In addition to the above, I need to also revert
>the following:
>
> b7e2e75a8c6062afe1dd88b0b299938e5d36dff8
> usb: gadget: drop unused USB_GADGET_MUSB_HDRC
>
>(This commit is clearly incorrect - code checking for this still
>remain in the tree (see e.g. N8x0 board file), so it's not "unused".)
Good catch, I didn't expect board files to depend on config symbols that
have no effect on the driver itself.
Please check the attached patch and let me know if it helps.
Thanks,
Daniel
>From 5f33d42f2dffb82d22b83a030f14fe2331a935b7 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Tue, 16 Jul 2013 08:19:49 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
dropped a config symbol that was unused by the musb core, but it turns
out that board support code still had references to it.
As the core now handles both dual role and host-only modes, we can just
pass MUSB_OTG as mode from board files.
Signed-off-by: Daniel Mack
---
arch/arm/mach-omap2/board-n8x0.c | 4
arch/arm/mach-omap2/usb-musb.c | 5 +
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index f6eeb87..827d150 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -122,11 +122,7 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data tusb_data = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
.mode = MUSB_OTG,
-#else
- .mode = MUSB_HOST,
-#endif
.set_power = tusb_set_power,
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..bc89723 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -38,11 +38,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
.mode = MUSB_OTG,
-#else
- .mode = MUSB_HOST,
-#endif
+
/* .clock is set dynamically */
.config = &musb_config,
--
1.8.1.4
Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
On Tuesday 16 July 2013 12:53 AM, Suman Anna wrote: > On 07/15/2013 05:01 AM, Rajendra Nayak wrote: >> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote: >>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote: On 07/11/2013 04:59 AM, Grygorii Strashko wrote: > Hi, > > On 07/11/2013 09:32 AM, Tony Lindgren wrote: >> * Felipe Balbi [130710 09:18]: >>> >>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: how about something like below ? It makes omap_device/hwmod and pm_runtime agree on the initial state of the device and will prevent ->runtime_resume() from being called on first pm_runtime_get*() done during probe. This is similar to what PCI bus does (if you look at pci_pm_init()). commit 59108a500b4ab4b1a5102648a3360276dbf7df6f Author: Felipe Balbi Date: Wed Jul 10 18:50:16 2013 +0300 arm: omap2plus: unidle devices which are about to probe in order to make HWMOD and pm_runtime agree on the initial state of the device, we will unidle the device and call pm_runtime_set_active() to tell pm_runtime that the device is really active. > Don't think that it's good idea ( > I've checked some driver's and think this patch will enable some devices > unpredictably: > - hwspinlock > - mailbox > - iommu > - ipu > All above devices need to be enabled on demand only (no > pm_runtime_get*() calls in probe). More over, some of them have very > specific enabling sequence - like ipu). > > May be Summan can say more on that. Indeed, this is a problem for any of the slave processor devices. mailbox and iommu would be slaves to the remoteproc and the drivers have a specific sequence of bringing up a processor. The current hwmod/omap_device code is such that these devices will be left in reset and the driver code use the omap_device_(de)assert_hardreset API together with omap_device_enable code to bring up the devices. The remoteproc driver also needs to assert the resets (there are other problems associated with using omap_device_idle for remoteproc and iommu) for bringing up the devices after a suspend sequence. hwspinlock and mailbox may get away since they are in CORE domain, but definitely an issue for iommu and remoteproc. I would think that this would also affect other compute devices like IVAHD, ISS, SGX. >>> >>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, >>> right? > > Yes, the omap_device_enable bails out if the reset lines are still > asserted, and the driver code deals with the resets currently. This code > essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is > added to the corresponding hwmods - we do not want the hwmod/omap_device > code to enable the processor IPs and leave the enabling/device > management to the driver. > >>> >>> /* >>> * If an IP block contains HW reset lines and all of them are >>> * asserted, we let integration code associated with that >>> * block handle the enable. We've received very little >>> * information on what those driver authors need, and until >>> * detailed information is provided and the driver code is >>> * posted to the public lists, this is probably the best we >>> * can do. >>> */ >>> if (_are_all_hardreset_lines_asserted(oh)) >>> return 0; >>> >>> What if this information is send back to omap_device() through a return >>> value >>> so omap_device() knows about this too, so it avoids marking the omap device >>> as >>> enabled? Wouldn't that fix the issue? >> >> I meant something like this.. >> >> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001 >> From: Rajendra Nayak >> Date: Mon, 15 Jul 2013 15:23:07 +0530 >> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to >> enable/idle/shutdown the hwmods >> >> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids >> enable/idle/shutdown operations as long as all the hard reset lines are >> kept asserted. However it does not return an error back to the caller (in >> some >> cases the omap_device layer) to communicate back the failure to operate on >> the >> hwmod. >> >> Fix this by making _enable()/_idle()/_shutdown() all return an error in such >> cases, and also fix the omap_device layer to look at the return values coming >> from hwmod operations before doing a omap_device level state transition. >> >> Signed-off-by: Rajendra Nayak > > Let me test this and get back to you if there are any issues. Great, thanks for testing. > > regards > Suman > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org Mor
Re: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3 platform
Tony, On Monday 08 July 2013 04:44 PM, Kishon Vijay Abraham I wrote: > This series fixes the USB enumeration issue caused because of the controller > not able to get a reference to the PHY because of incorrect binding in the > board file. > > In the case of non-dt boot, the platform specific initialization file > (board file) will do usb_bind_phy that binds the usb controller with the > PHY using device names. After the device names are created using > PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't > work reliably (since the device name changes). Hence the usb controller > is made to use labels for getting the PHY. > > Here the PHY name is added in the plat data of USB controller device which > should be used by the controller driver to get the PHY. > Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to > be used by the controller to get the PHY by name. You haven't picked this patch series? -Kishon -- 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 8/8] ARM: DRA7: Kconfig: Increase the default gpio count
On Sunday 14 July 2013 05:37 PM, Kevin Hilman wrote: > On 07/09/2013 08:27 AM, Rajendra Nayak wrote: >> From: R Sricharan >> >> DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs. >> In order for the gpiolib to detect and initialize these >> additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set >> to 512 instead of present 256. > nit: the patch itself doesn't change 256 to 512, but just adds another > Kconfig default. > > Kevin hmm, ok. Will reword the $subject and commit accordingly Regards, Sricharan >> Signed-off-by: R Sricharan >> Signed-off-by: Rajendra Nayak >> --- >> arch/arm/Kconfig |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 5ef7af0..9faed52 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -1599,7 +1599,7 @@ config LOCAL_TIMERS >> config ARCH_NR_GPIO >> int >> default 1024 if ARCH_SHMOBILE || ARCH_TEGRA >> -default 512 if SOC_OMAP5 >> +default 512 if SOC_OMAP5 || SOC_DRA7XX >> default 512 if ARCH_KEYSTONE >> default 392 if ARCH_U8500 >> default 352 if ARCH_VT8500 >> -- 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 2/2] pwm: Add PWM polarity flag macros for DT
On 07/15/2013 07:10 PM, Laurent Pinchart wrote: > On Friday 12 July 2013 08:42:41 Stephen Warren wrote: ... >> I think the values for any common system-wide flags should be defined >> once in some system-wide place, and the values for any HW-specific >> values should be defined only in the documentation for that specific HW. >> You could try and avoid conflicts by either: >> >> a) Allocating system-wide flags from bit 0 up, and HW-specific flags >> from bit 31 down. >> >> or: >> >> b) Using 1 cell for standard flags, and a separate cell for any >> HW-specific flags. Drivers can quite easily adapt to adding extra cells >> to #pwm-cells, thus making adding a HW-specific cell later >> backwards-compatible. > > I wasn't referring to HW-specific flags, but rather to system-wide flags that > might not be supported by all drivers. If we later add new system-wide flags > I > think the individual DT bindings should explicitly document which flags they > support. Shouldn't all system-wide flags be supported by all HW, perhaps being implemented by the core subsystem rather than individual drivers to ensure that? Consider the case of the GPIO active-low flag which is actually implemented in SW, hence can work with any GPIO controller. Perhaps that's not possible in all cases, in which case, yes, it does make sense to define which of the common flags a particular HW module supports. But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. -- 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 2/2] pwm: Add PWM polarity flag macros for DT
Hello,
On Friday 12 July 2013 11:40:44 Stephen Warren wrote:
> On 07/12/2013 11:24 AM, Thierry Reding wrote:
> > On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
> >> On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
> >>> Hi Stephen,
> >
> > [...]
> >
> >>> What about splitting it in three patches that
> >>>
> >>> - add the include/dt-bindings/pwm/pwm.h header, and update
> >>> include/linux/pwm.h and
> >>> Documentation/devicetree/bindings/pwm/pwm.txt
> >>>
> >>> - update the rest of the documentation
> >>>
> >>> - update the .dts files
> >>
> >> I think that sounds reasonable.
> >
> > Shouldn't the addition of include/dt-bindings/pwm/pwm.h be separate from
> > its inclusion in include/linux/pwm.h so that it can be moved more easily
> > (cherry-picked) to a separate repository?
>
> I'm fine with that being another separate patch. However, I doubt cherry-
> picking is an issue here; when the separate DT repo is created, it seems
> likely that someone will simply copy the latest files from the latest Linux
> kernel in order to populate the tree. cherry-picking probably won't work
> because:
>
> a) I doubt that the DT binding/header additions have always been kept
> separate from kernel code changes in all of Linux's history.
>
> b) I wouldn't be remotely surprised if the layout of the new repo was
> entirely different to the kernel source tree layout, so direct cherry-pick
> wouldn't work.
>
> c) Not having a common git history would make adding a kernel remote into
> the DT repo rather odd.
>
> (b) and (c) would at leat require some kind of git filter operation rather
> than cherry-pick, and this issue could be solve in that filter definition.
I agree with the reasoning, so I'll implement the patch split scheme described
above unless someone objects.
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> >
> > enum pwm_polarity {
> >
> > - PWM_POLARITY_NORMAL, - PWM_POLARITY_INVERSED, +
> > PWM_POLARITY_NORMAL = 0, + PWM_POLARITY_INVERSED = 1,
> >
> > };
>
> Rather than manually editing that to ensure the enum matches the DT
> bindings header, the whole point of making a separate
> directory was that drivers could include the binding header files
> directly to avoid having to duplicate the constant definitions. Can't
> include and remove that enum?
> >>>
> >>> We could do that, but we would then need to modify all drivers to
> >>> replace enum_pwm_polarity with unsigned int. Thierry, what's your
> >>> opinion on this ?
> >>
> >> Or perhaps we could keep the enums around, but force the values to match
> >> the DT constants:
> >>
> >> enum pwm_polarity { PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
> >> PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED, };
> >>
> >> (although obviously you'd need to avoid the enum and DT constants having
> >> the same name).
> >
> > I think I've seen stuff like the following done in a few header files to
> > keep compatibility between enums and defines.
> >
> > enum foo { BAR, #define BAR BAR BAZ, #define BAZ BAZ };
> >
> > Which, as I understand it, won't work in this case because DTC can only
> > cope with plain cpp files?
>
> Yeah, dtc doesn't understand "enum", so you can't include an enum definition
> in a DT file. You have to share simple #define headers between DT and kernel
> code.
>
> >> Although this brings up one point: let's say we support ACPI/..
> >> bindings in the future. The enum possibly can't match the binding
> >> values from every different kind of binding definition (DT, ACPI,
> >> ...) so perhaps rather than changing the enum definition in
> >> , what we should be doing is mapping between the
> >> different name-spaces in whatever of_xlate function exists for
> >> the PWM flags cell. That would be more flexible.
> >
> > I'm not quite sure what exactly you are suggesting here. Can you
> > elaborate?
>
> Suppose ACPI (or whatever else) starts representing PWM devices. Suppose the
> author isn't aware that DT exists, represents PWM devices and/or has already
> defined some PWM-related flags. So, ACPI picks bit 5 in some data value to
> represent inverted, rather than bit 0. Then, there is no way that all of [
> (a) DT binding PWM flags (b) ACPI PWM flags (c) Linux's enum foo ] can use
> the same values. Hence, some mapping is required between them.
>
> The typical way to do this is to define an "of_xlate" function which
> converts from DT cell values to Linux-internal representation. Presumably if
> we added an ACPI parser, there'd be some equivalent for that.
>
> So, what I'm arguing for is that of_pwm_simple_xlate() (or any other custom
> xlate function) should include both and
> , and contain explicit code to convert between the two name-
> spaces of flags definitions. Since those two name-spaces currently are 100%
> identical, presumably if the code is written in the right way, the compiler
> will actually just optimize it all
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Hi Stephen, On Friday 12 July 2013 08:42:41 Stephen Warren wrote: > On 07/12/2013 05:01 AM, Laurent Pinchart wrote: > > On Thursday 11 July 2013 14:06:44 Stephen Warren wrote: > >> On 07/11/2013 01:32 PM, Thierry Reding wrote: > >>> On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote: > On 07/11/2013 09:36 AM, Thierry Reding wrote: > > On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart > > wrote: [...] > > > >> diff --git > >> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt > >> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt > >> index de0eaed..be09be4 100644 --- > >> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt > >> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt > >> @@ -4,9 +4,9 @@ Required properties: - compatible: should be > >> "atmel,tcb-pwm" - #pwm-cells: Should be 3. The first cell > >> specifies the per-chip index of the PWM to use, the second > >> cell is the period in nanoseconds and - bit 0 in the third > >> cell is used to encode the polarity of PWM output. - Set bit > >> 0 of the third cell in PWM specifier to 1 for inverse > >> polarity & - set to 0 for normal polarity. + the third cell > >> is used to encode the polarity of PWM output. Set the + > >> PWM_POLARITY_NORMAL flag for normal polarity or the > >> PWM_POLARITY_INVERSED + flag for inverted polarity. PWM > >> flags are defined in . - tc-block: The > >> Timer Counter block to use as a PWM chip. > > > >> Example: > > I'd prefer for the original text to stay in place and the reference to > > the dt-bindings/pwm/pwm.h file to go below that block. > > I disagree here. The whole point of creating header files for the > constants in binding definitions was so that you wouldn't have to > duplicate all the values into the binding definitions. Rather, you'd > simply say "see ". > >>> > >>> But that's not something that this patch solves. > >> > >> Well, if the comments I made on the patch re: that should > >> simply #include instead of duplicating the > >> constants, then yet this patch will solve that. There will be a single > >> place where the constants are defined. > > > > As explained in another reply, this would require replacing the enum with > > an unsigned int. I can write a patch if we agree on this. > > > >>> And it could be solved even in the absence of the header file defining > >>> the symbolic constants. If all the standard flags that > >>> dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt (they > >>> actually are) then referring to that document as the canonical source > >>> works equally well. > >> > >> If that's all the happens, then there will still be duplication > >> between pwm.txt and . > > > > I've explicitly mentioned the flags in individual DT bindings to ease > > adding new flags in the future. At the moment the defined flags are > > either all supported or not used at all by drivers. If we later add a new > > flag supported by a subset of drivers only the driver bindings should > > list supported flags for each driver. > > > > I'm fine with removing the explicit mentions of individual flags right now > > and adding it back when needed if you think that's better. > > I think the values for any common system-wide flags should be defined > once in some system-wide place, and the values for any HW-specific > values should be defined only in the documentation for that specific HW. > You could try and avoid conflicts by either: > > a) Allocating system-wide flags from bit 0 up, and HW-specific flags > from bit 31 down. > > or: > > b) Using 1 cell for standard flags, and a separate cell for any > HW-specific flags. Drivers can quite easily adapt to adding extra cells > to #pwm-cells, thus making adding a HW-specific cell later > backwards-compatible. I wasn't referring to HW-specific flags, but rather to system-wide flags that might not be supported by all drivers. If we later add new system-wide flags I think the individual DT bindings should explicitly document which flags they support. -- Regards, Laurent Pinchart -- 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 v6] usb: dwc3: use extcon fwrk to receive connect/disconnect
On 07/16/2013 12:51 AM, Felipe Balbi wrote: > On Mon, Jul 15, 2013 at 09:09:02PM +0530, Kishon Vijay Abraham I wrote: >> Modified dwc3-omap to receive connect and disconnect notification using >> extcon framework. Also did the necessary cleanups required after >> adapting to extcon framework. >> >> Signed-off-by: Kishon Vijay Abraham I >> Acked-by: Felipe Balbi >> Acked-by: Chanwoo Choi >> --- >> This patch should be applied after all of the extcon patchset will be applied >> because this patch has dependency of extcon patch related to DT. >> http://goo.gl/Tu3qW >> >> Changes from v5: >> * rebased to 3.11-rc1 >> Changes from v4: >> * checked the return values of extcon_register_interest and print an error >> message. Note that I dint do return since there might be cases where >> one of USB (device mode) or USB-HOST (host mode) might succeed. >> * Added depends on of EXTCON in usb_dwc3. Only some platforms might >> be using EXTCON, but inorder to avoid compilation errors, added >> depends on >> Changes from v3: >> * did #include of of_extcon.h after Chanwoo resent the patch separating >> extcon-class.c from of_extcon.c >> Changes from v2: >> * updated the Documentation with dwc3 dt binding information. >> * used of_extcon_get_extcon_dev to get extcon device from device tree data. >> Changes from v1: >> * regulator enable/disable is now done here instead of palmas-usb as some >> users >> of palmas-usb wont need regulator. >> Documentation/devicetree/bindings/usb/omap-usb.txt |5 + >> drivers/usb/dwc3/Kconfig |1 + >> drivers/usb/dwc3/dwc3-omap.c | 125 >> +--- >> 3 files changed, 112 insertions(+), 19 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt >> b/Documentation/devicetree/bindings/usb/omap-usb.txt >> index 57e71f6..9088ab0 100644 >> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt >> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt >> @@ -53,6 +53,11 @@ OMAP DWC3 GLUE >> It should be set to "1" for HW mode and "2" for SW mode. >> - ranges: the child address space are mapped 1:1 onto the parent address >> space >> >> +Optional Properties: >> + - extcon : phandle for the extcon device omap dwc3 uses to detect >> + connect/disconnect events. >> + - vbus-supply : phandle to the regulator device tree node if needed. >> + >> Sub-nodes: >> The dwc3 core should be added as subnode to omap dwc3 glue. >> - dwc3 : >> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig >> index 757aa18..08a9fab 100644 >> --- a/drivers/usb/dwc3/Kconfig >> +++ b/drivers/usb/dwc3/Kconfig >> @@ -1,6 +1,7 @@ >> config USB_DWC3 >> tristate "DesignWare USB3 DRD Core Support" >> depends on (USB || USB_GADGET) && GENERIC_HARDIRQS >> +depends on EXTCON > > can you rebase this on top of 'testing' branch. I have a patch there > which give glue layers their own Kconfig symbols. If you do that, I can > queue this patch myself for v3.12, unless we have dependencies on other > patches which aren't in mainline, in which case, I'd ask to simply > remove this Kconfig change for now. > Dear Felipe and Kishon, We have some confusion about applying this patch. I already applied this patch on extcon-next branch for v3.12. This patch has the dependency on below extcon patch. [PATCH] usb: dwc3: use extcon fwrk to receive connect/disconnect - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next&id=68517aac722c8c3e0c153b3ede40aace25cb66fa [PATCH] extcon: Add an API to get extcon device from dt node - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next&id=cb28faede03de7abe82336c3648771a01f5fe225 If Felipe would apply this patch usb.git for v3.12, I think you should include extcon patch together. [PATCH] extcon: Add an API to get extcon device from dt node - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next&id=cb28faede03de7abe82336c3648771a01f5fe225 The dependency related to patch cause this confusion. What is your opinion? Thanks, Chanwoo Choi -- 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
v3.11-rc1 USB regressions
Hi, I think USB tree introduced regressions in v3.11-rc1, at least for some OMAP devices using legacy boot. I have only bisected these; I have no idea what the real fixes are but the following reverts make Nokia OMAP2+ boards again usable for kernel development work (they need working USB connection for interacting with the device): 1) USB peripheral mode (g_ether) is broken on Nokia N900, N950 and N9 (USB_MUSB_OMAP2PLUS). To make it it work, I need to revert three commits: 09fc7d22b024692b2fe8a943b246de1af307132b usb: musb: fix incorrect usage of resource pointer (Reverting this fixes the g_ether probe failure "couldn't find an available UDC") fe4cb0912f8e737f8e4b8b38b9e692f8062f5423 usb: musb: gadget: remove hcd initialization (Reverting this fixes error "cdc_ether: probe of 4-1:1.0 failed with error -110" seen on the host side.) 8b125df5b24cfb0ec7fa1971e343cc0badc1827d usb: musb: eliminate musb_to_hcd (Reverting this fixes compilation error cause by the previous revert.) 2) USB peripheral mode (g_ether) is broken also on Nokia N800 and N810 (USB_MUSB_TUSB6010). In addition to the above, I need to also revert the following: b7e2e75a8c6062afe1dd88b0b299938e5d36dff8 usb: gadget: drop unused USB_GADGET_MUSB_HDRC (This commit is clearly incorrect - code checking for this still remain in the tree (see e.g. N8x0 board file), so it's not "unused".) A. -- 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: Boot hang regression 3.10.0-rc4 -> 3.10.0
On 07/15/2013 05:01 AM, Rajendra Nayak wrote: > On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote: >> On Friday 12 July 2013 06:10 AM, Suman Anna wrote: >>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote: Hi, On 07/11/2013 09:32 AM, Tony Lindgren wrote: > * Felipe Balbi [130710 09:18]: >> >> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: >>> how about something like below ? It makes omap_device/hwmod and >>> pm_runtime agree on the initial state of the device and will prevent >>> ->runtime_resume() from being called on first pm_runtime_get*() done >>> during probe. >>> >>> This is similar to what PCI bus does (if you look at pci_pm_init()). >>> >>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f >>> Author: Felipe Balbi >>> Date: Wed Jul 10 18:50:16 2013 +0300 >>> >>> arm: omap2plus: unidle devices which are about to probe >>> >>> in order to make HWMOD and pm_runtime agree on the >>> initial state of the device, we will unidle the device >>> and call pm_runtime_set_active() to tell pm_runtime >>> that the device is really active. Don't think that it's good idea ( I've checked some driver's and think this patch will enable some devices unpredictably: - hwspinlock - mailbox - iommu - ipu All above devices need to be enabled on demand only (no pm_runtime_get*() calls in probe). More over, some of them have very specific enabling sequence - like ipu). May be Summan can say more on that. >>> >>> Indeed, this is a problem for any of the slave processor devices. >>> mailbox and iommu would be slaves to the remoteproc and the drivers have >>> a specific sequence of bringing up a processor. The current >>> hwmod/omap_device code is such that these devices will be left in reset >>> and the driver code use the omap_device_(de)assert_hardreset API >>> together with omap_device_enable code to bring up the devices. The >>> remoteproc driver also needs to assert the resets (there are other >>> problems associated with using omap_device_idle for remoteproc and >>> iommu) for bringing up the devices after a suspend sequence. hwspinlock >>> and mailbox may get away since they are in CORE domain, but definitely >>> an issue for iommu and remoteproc. I would think that this would also >>> affect other compute devices like IVAHD, ISS, SGX. >> >> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, >> right? Yes, the omap_device_enable bails out if the reset lines are still asserted, and the driver code deals with the resets currently. This code essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is added to the corresponding hwmods - we do not want the hwmod/omap_device code to enable the processor IPs and leave the enabling/device management to the driver. >> >> /* >> * If an IP block contains HW reset lines and all of them are >> * asserted, we let integration code associated with that >> * block handle the enable. We've received very little >> * information on what those driver authors need, and until >> * detailed information is provided and the driver code is >> * posted to the public lists, this is probably the best we >> * can do. >> */ >> if (_are_all_hardreset_lines_asserted(oh)) >> return 0; >> >> What if this information is send back to omap_device() through a return value >> so omap_device() knows about this too, so it avoids marking the omap device >> as >> enabled? Wouldn't that fix the issue? > > I meant something like this.. > > From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001 > From: Rajendra Nayak > Date: Mon, 15 Jul 2013 15:23:07 +0530 > Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to > enable/idle/shutdown the hwmods > > For IP blocks (mainly processors) which have hard reset lines, hwmod avoids > enable/idle/shutdown operations as long as all the hard reset lines are > kept asserted. However it does not return an error back to the caller (in some > cases the omap_device layer) to communicate back the failure to operate on the > hwmod. > > Fix this by making _enable()/_idle()/_shutdown() all return an error in such > cases, and also fix the omap_device layer to look at the return values coming > from hwmod operations before doing a omap_device level state transition. > > Signed-off-by: Rajendra Nayak Let me test this and get back to you if there are any issues. regards Suman -- 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] [RFC] usb: dwc3: removal of assumption that usb3 phy always present
On Fri, Jul 05, 2013 at 09:35:05AM -0500, Ruchika Kharwar wrote: > > On 07/04/2013 01:26 AM, Ruchika Kharwar wrote: > >DRA7XX has several USB OTG subsystems. USB_OTG_SS1 includes a USB1 and USB2 > >phy. USB_OTG_SS2 includes only a USB2 phy. > >This patch allows the dwc3 probe to continue if a usb3_phy is not found. > The need for this will go away as soon as "of_get_maximum_speed" is > introduced. The speed can then be used to determine if a USB3 phy is > required or not for dra7xx as well. there is one problem with this approach (even my approach which I had cooked before). I was testing OMAP5 today (finally got most pieces in mainline, so I could test something with little out of tree), and as it turns out, the USB3PHY DPLL is used to generate the PIPE3 clock and that clock is used to power some important part of the IP. From what I could grasp out of OMAP5 ES2.0 TRM and Synopsys databook, I believe OMAP5 decided to tie ram_clk to pipe3_clk (the PIP3 bus clock) and if we let USB3 PHY be optional on OMAP5, we might end up with broken DTS files which cause device not to work. That aside, what caught my attention is how the problem exposes itself: We end up in a situation where DWC3_DEPCMD_SETEPCONFIG never completes although the previous DWC3_DEPCMD_DEPSTARTCFG completes just fine. This happens early on, when we're trying to enable physical endpoint 0, then the driver bails out. I'm assuming that DWC3_DEPCMD_DEPSTARTCFG is very easy to process, maybe it just puts the internal FSM into a post-idle state which simply waits for the endpoint configuration to come through the registers while, in turn, DWC3_DEPCMD_DEPSTARTCFG is far more complex to process and needs other parts of the IP to be fully powered and clocked in order to complete. If my speculation is correct thus far, it also means that those blocks are somehow powered by pipe3_clk (or a derivation of it). It would be nice if SNPS could shed some light here, but I'll continue digging the docs, for now the feature of optional USB3PHY will be pending in a separate branch while I try to get all information related to this problem. The decision came after figuring out that if we don't usb_phy_init(dwc->usb3_phy), OMAP5 would never, ever work because the USB3 PHY DPLL is locked in ->init() callback of that driver in ordre to conserve power. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] remove vlan tags in CPSW dual emac mode
On 7/15/2013 9:20 PM, Mark Jackson wrote: > On 15/07/13 13:45, Mugunthan V N wrote: >> On 7/13/2013 12:55 AM, Mark Jackson wrote: >>> On 12/07/13 19:35, Mugunthan V N wrote: On 7/12/2013 7:27 PM, Mark Jackson wrote: >>> [snip] >>> > Just to update this (old) thread ... > > I can still confirm that *without* the above patch, I am *unable* to use > both network > ports on our AM335x board. > >>> [snip] >>> > So I'm not sure what's wrong, but it's *definitely* not correct. > > I am sure that current code in mainline works for Dual EMAC. I can test it again and share the images with you if are interested. But had tested with DHCP on both the interfaces. >>> Hmmm ... well it's not working for me. What hardware are you testing it on >>> ? >>> >>> I tried DHCP to start with, and switched to static IP when that failed. >>> Then I recalled this patch and re-applied it ... hey presto !! >>> >>> Markus, are you still using this patch ? >>> >> Today I have tested the Dual EMAC on my am335x-evmsk and its working fine >> with >> net/master branch. >> I had 3 patches additional to net/master in which two for basic boot of EVMsk >> and one for enabling Dual EMAC. I had pushed the branch in the below repo >> repo: >> git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git >> branch: dual-emac > Okay ... I can't test that at the moment as I can only boot from MMC as > there's > currently no support for MMC booting in the mainline kernel. > > So ... the code works for you, but not for me. > > I guess the other difference is that I'm not using the same PHY (we use a > 10/100 > SMSC 8710A, not the GbE Atheros part). > > Could that make any difference ? > > Markus, are you still seeing the same issue ? What PHY are you using ? > There is no relation between what you used vs vlan aware mode in CPSW. I don't have a board with SMSC phy. If I have I could have helped you to bring up Dual EMAC. Regards Mugunthan V N -- 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] ASoC: omap: Enable COMPILE_TEST build for DT platforms
On Mon, Jul 15, 2013 at 06:43:46PM +0200, Peter Ujfalusi wrote: > On 07/15/2013 05:57 PM, Mark Brown wrote: > > From: Mark Brown > > The DT platforms don't have any source dependency on any OMAP stuff so > > allow them to be built when COMPILE_TEST is enabled. > The OMAP3 generic machine driver could be also included in this patch: > SND_OMAP_SOC_OMAP_TWL4030 There's no need for that - it has no dependencies other than the TWL4030 core driver and SND_OMAP_SOC so as soon as SND_OMAP_SOC can be enabled it is too. signature.asc Description: Digital signature
Re: [PATCH] ASoC: omap: Enable COMPILE_TEST build for DT platforms
Hi Mark, On 07/15/2013 05:57 PM, Mark Brown wrote: > From: Mark Brown > > The DT platforms don't have any source dependency on any OMAP stuff so > allow them to be built when COMPILE_TEST is enabled. The OMAP3 generic machine driver could be also included in this patch: SND_OMAP_SOC_OMAP_TWL4030 > Signed-off-by: Mark Brown > --- Otherwise: Acked-by: Peter Ujfalusi > sound/soc/omap/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig > index 9f5d55e..68dfc0a 100644 > --- a/sound/soc/omap/Kconfig > +++ b/sound/soc/omap/Kconfig > @@ -1,6 +1,6 @@ > config SND_OMAP_SOC > tristate "SoC Audio for the Texas Instruments OMAP chips" > - depends on ARCH_OMAP && DMA_OMAP > + depends on (ARCH_OMAP && DMA_OMAP) || COMPILE_TEST > select SND_SOC_DMAENGINE_PCM > > config SND_OMAP_SOC_DMIC > @@ -26,7 +26,7 @@ config SND_OMAP_SOC_N810 > > config SND_OMAP_SOC_RX51 > tristate "SoC Audio support for Nokia RX-51" > - depends on SND_OMAP_SOC && MACH_NOKIA_RX51 > + depends on SND_OMAP_SOC && (MACH_NOKIA_RX51 || COMPILE_TEST) > select SND_OMAP_SOC_MCBSP > select SND_SOC_TLV320AIC3X > select SND_SOC_TPA6130A2 > @@ -87,7 +87,7 @@ config SND_OMAP_SOC_OMAP_TWL4030 > > config SND_OMAP_SOC_OMAP_ABE_TWL6040 > tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec" > - depends on TWL6040_CORE && SND_OMAP_SOC && ARCH_OMAP4 > + depends on TWL6040_CORE && SND_OMAP_SOC && (ARCH_OMAP4 || COMPILE_TEST) > select SND_OMAP_SOC_DMIC > select SND_OMAP_SOC_MCPDM > select SND_SOC_TWL6040 > -- Péter -- 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] ASoC: omap: Enable COMPILE_TEST build for DT platforms
On Mon, Jul 15, 2013 at 05:26:05PM +0100, Mark Brown wrote: > On Mon, Jul 15, 2013 at 07:00:45PM +0300, Felipe Balbi wrote: > > On Mon, Jul 15, 2013 at 04:57:56PM +0100, Mark Brown wrote: > > > @@ -26,7 +26,7 @@ config SND_OMAP_SOC_N810 > > > > config SND_OMAP_SOC_RX51 > > > tristate "SoC Audio support for Nokia RX-51" > > > - depends on SND_OMAP_SOC && MACH_NOKIA_RX51 > > > + depends on SND_OMAP_SOC && (MACH_NOKIA_RX51 || COMPILE_TEST) > > > RX51 is OMAP3, and that's DT at all. This is likely just a case of ^ not > > updating commit log. > > Sentence parse grammar not. > > However... if you look at the driver it actually does have DT support > in there, it checks for the machine type or for compatibility with n900. > Probably needs an ARM dependency which I'll add due to the machine type > check. alright. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ASoC: omap: Enable COMPILE_TEST build for DT platforms
On Mon, Jul 15, 2013 at 07:00:45PM +0300, Felipe Balbi wrote: > On Mon, Jul 15, 2013 at 04:57:56PM +0100, Mark Brown wrote: > > @@ -26,7 +26,7 @@ config SND_OMAP_SOC_N810 > > config SND_OMAP_SOC_RX51 > > tristate "SoC Audio support for Nokia RX-51" > > - depends on SND_OMAP_SOC && MACH_NOKIA_RX51 > > + depends on SND_OMAP_SOC && (MACH_NOKIA_RX51 || COMPILE_TEST) > RX51 is OMAP3, and that's DT at all. This is likely just a case of > updating commit log. Sentence parse grammar not. However... if you look at the driver it actually does have DT support in there, it checks for the machine type or for compatibility with n900. Probably needs an ARM dependency which I'll add due to the machine type check. signature.asc Description: Digital signature
Re: [PATCH] ASoC: omap: Enable COMPILE_TEST build for DT platforms
Hi, On Mon, Jul 15, 2013 at 04:57:56PM +0100, Mark Brown wrote: > @@ -26,7 +26,7 @@ config SND_OMAP_SOC_N810 > > config SND_OMAP_SOC_RX51 > tristate "SoC Audio support for Nokia RX-51" > - depends on SND_OMAP_SOC && MACH_NOKIA_RX51 > + depends on SND_OMAP_SOC && (MACH_NOKIA_RX51 || COMPILE_TEST) RX51 is OMAP3, and that's DT at all. This is likely just a case of updating commit log. -- balbi signature.asc Description: Digital signature
[PATCH] ASoC: omap: Enable COMPILE_TEST build for DT platforms
From: Mark Brown The DT platforms don't have any source dependency on any OMAP stuff so allow them to be built when COMPILE_TEST is enabled. Signed-off-by: Mark Brown --- sound/soc/omap/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 9f5d55e..68dfc0a 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -1,6 +1,6 @@ config SND_OMAP_SOC tristate "SoC Audio for the Texas Instruments OMAP chips" - depends on ARCH_OMAP && DMA_OMAP + depends on (ARCH_OMAP && DMA_OMAP) || COMPILE_TEST select SND_SOC_DMAENGINE_PCM config SND_OMAP_SOC_DMIC @@ -26,7 +26,7 @@ config SND_OMAP_SOC_N810 config SND_OMAP_SOC_RX51 tristate "SoC Audio support for Nokia RX-51" - depends on SND_OMAP_SOC && MACH_NOKIA_RX51 + depends on SND_OMAP_SOC && (MACH_NOKIA_RX51 || COMPILE_TEST) select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC3X select SND_SOC_TPA6130A2 @@ -87,7 +87,7 @@ config SND_OMAP_SOC_OMAP_TWL4030 config SND_OMAP_SOC_OMAP_ABE_TWL6040 tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec" - depends on TWL6040_CORE && SND_OMAP_SOC && ARCH_OMAP4 + depends on TWL6040_CORE && SND_OMAP_SOC && (ARCH_OMAP4 || COMPILE_TEST) select SND_OMAP_SOC_DMIC select SND_OMAP_SOC_MCPDM select SND_SOC_TWL6040 -- 1.8.3.2 -- 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 v6] usb: dwc3: use extcon fwrk to receive connect/disconnect
On Mon, Jul 15, 2013 at 09:09:02PM +0530, Kishon Vijay Abraham I wrote: > Modified dwc3-omap to receive connect and disconnect notification using > extcon framework. Also did the necessary cleanups required after > adapting to extcon framework. > > Signed-off-by: Kishon Vijay Abraham I > Acked-by: Felipe Balbi > Acked-by: Chanwoo Choi > --- > This patch should be applied after all of the extcon patchset will be applied > because this patch has dependency of extcon patch related to DT. > http://goo.gl/Tu3qW > > Changes from v5: > * rebased to 3.11-rc1 > Changes from v4: > * checked the return values of extcon_register_interest and print an error > message. Note that I dint do return since there might be cases where > one of USB (device mode) or USB-HOST (host mode) might succeed. > * Added depends on of EXTCON in usb_dwc3. Only some platforms might > be using EXTCON, but inorder to avoid compilation errors, added > depends on > Changes from v3: > * did #include of of_extcon.h after Chanwoo resent the patch separating > extcon-class.c from of_extcon.c > Changes from v2: > * updated the Documentation with dwc3 dt binding information. > * used of_extcon_get_extcon_dev to get extcon device from device tree data. > Changes from v1: > * regulator enable/disable is now done here instead of palmas-usb as some > users > of palmas-usb wont need regulator. > Documentation/devicetree/bindings/usb/omap-usb.txt |5 + > drivers/usb/dwc3/Kconfig |1 + > drivers/usb/dwc3/dwc3-omap.c | 125 > +--- > 3 files changed, 112 insertions(+), 19 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt > b/Documentation/devicetree/bindings/usb/omap-usb.txt > index 57e71f6..9088ab0 100644 > --- a/Documentation/devicetree/bindings/usb/omap-usb.txt > +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt > @@ -53,6 +53,11 @@ OMAP DWC3 GLUE > It should be set to "1" for HW mode and "2" for SW mode. > - ranges: the child address space are mapped 1:1 onto the parent address > space > > +Optional Properties: > + - extcon : phandle for the extcon device omap dwc3 uses to detect > + connect/disconnect events. > + - vbus-supply : phandle to the regulator device tree node if needed. > + > Sub-nodes: > The dwc3 core should be added as subnode to omap dwc3 glue. > - dwc3 : > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index 757aa18..08a9fab 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -1,6 +1,7 @@ > config USB_DWC3 > tristate "DesignWare USB3 DRD Core Support" > depends on (USB || USB_GADGET) && GENERIC_HARDIRQS > + depends on EXTCON can you rebase this on top of 'testing' branch. I have a patch there which give glue layers their own Kconfig symbols. If you do that, I can queue this patch myself for v3.12, unless we have dependencies on other patches which aren't in mainline, in which case, I'd ask to simply remove this Kconfig change for now. -- balbi signature.asc Description: Digital signature
Re: [PATCH] remove vlan tags in CPSW dual emac mode
On 15/07/13 13:45, Mugunthan V N wrote: > On 7/13/2013 12:55 AM, Mark Jackson wrote: >> On 12/07/13 19:35, Mugunthan V N wrote: >>> On 7/12/2013 7:27 PM, Mark Jackson wrote: >> [snip] >> Just to update this (old) thread ... I can still confirm that *without* the above patch, I am *unable* to use both network ports on our AM335x board. >> [snip] >> So I'm not sure what's wrong, but it's *definitely* not correct. >>> I am sure that current code in mainline works for Dual EMAC. I can test it >>> again and share the images with you if are interested. But had tested with >>> DHCP >>> on both the interfaces. >> Hmmm ... well it's not working for me. What hardware are you testing it on ? >> >> I tried DHCP to start with, and switched to static IP when that failed. >> Then I recalled this patch and re-applied it ... hey presto !! >> >> Markus, are you still using this patch ? >> > Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with > net/master branch. > I had 3 patches additional to net/master in which two for basic boot of EVMsk > and one for enabling Dual EMAC. I had pushed the branch in the below repo > repo: > git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git > branch: dual-emac Okay ... I can't test that at the moment as I can only boot from MMC as there's currently no support for MMC booting in the mainline kernel. So ... the code works for you, but not for me. I guess the other difference is that I'm not using the same PHY (we use a 10/100 SMSC 8710A, not the GbE Atheros part). Could that make any difference ? Markus, are you still seeing the same issue ? What PHY are you using ? Cheers Mark J. -- 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 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
On Mon, Jul 15, 2013 at 09:13:32PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 15 July 2013 09:03 PM, Felipe Balbi wrote:
> > From: Benoit Cousson
> >
> > without that hwmod data, USB3 will not in OMAP5 boards.
> >
> > While at that, also fix DTS data to pass reg property,
> > otherwise driver won't probe.
> >
> > Signed-off-by: Benoit Cousson
> > Signed-off-by: Felipe Balbi
> > ---
> > arch/arm/boot/dts/omap5.dtsi | 3 +-
> > arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45
> > ++
> > 2 files changed, 47 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> > index 5c99f19..4e41409 100644
> > --- a/arch/arm/boot/dts/omap5.dtsi
> > +++ b/arch/arm/boot/dts/omap5.dtsi
> > @@ -652,10 +652,11 @@
> > };
> > };
> >
> > - ocp2scp {
> > + ocp2scp@4a08 {
>
> While at that, can we also name it ocp2scp1 since we have 3 instances of
> ocp2scp and it'll conflict when we want to add it for SATA and PCIE.
Tony/Benoit, you want that in same patch or as a separate patch
altogether ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
Hi,
On Monday 15 July 2013 09:03 PM, Felipe Balbi wrote:
> From: Benoit Cousson
>
> without that hwmod data, USB3 will not in OMAP5 boards.
>
> While at that, also fix DTS data to pass reg property,
> otherwise driver won't probe.
>
> Signed-off-by: Benoit Cousson
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/boot/dts/omap5.dtsi | 3 +-
> arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45
> ++
> 2 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 5c99f19..4e41409 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -652,10 +652,11 @@
> };
> };
>
> - ocp2scp {
> + ocp2scp@4a08 {
While at that, can we also name it ocp2scp1 since we have 3 instances of
ocp2scp and it'll conflict when we want to add it for SATA and PCIE.
Thanks
Kishon
--
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 v6] usb: dwc3: use extcon fwrk to receive connect/disconnect
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
This patch should be applied after all of the extcon patchset will be applied
because this patch has dependency of extcon patch related to DT.
http://goo.gl/Tu3qW
Changes from v5:
* rebased to 3.11-rc1
Changes from v4:
* checked the return values of extcon_register_interest and print an error
message. Note that I dint do return since there might be cases where
one of USB (device mode) or USB-HOST (host mode) might succeed.
* Added depends on of EXTCON in usb_dwc3. Only some platforms might
be using EXTCON, but inorder to avoid compilation errors, added
depends on
Changes from v3:
* did #include of of_extcon.h after Chanwoo resent the patch separating
extcon-class.c from of_extcon.c
Changes from v2:
* updated the Documentation with dwc3 dt binding information.
* used of_extcon_get_extcon_dev to get extcon device from device tree data.
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some users
of palmas-usb wont need regulator.
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/dwc3-omap.c | 125 +---
3 files changed, 112 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..9088ab0 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE
It should be set to "1" for HW mode and "2" for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address space
+Optional Properties:
+ - extcon : phandle for the extcon device omap dwc3 uses to detect
+ connect/disconnect events.
+ - vbus-supply : phandle to the regulator device tree node if needed.
+
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 757aa18..08a9fab 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,7 @@
config USB_DWC3
tristate "DesignWare USB3 DRD Core Support"
depends on (USB || USB_GADGET) && GENERIC_HARDIRQS
+ depends on EXTCON
select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 077f110..b26c2a4 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,13 +43,15 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
#include
+#include
+#include
+#include
#include
@@ -155,9 +157,21 @@ struct dwc3_omap {
u32 revision;
u32 dma_status:1;
+
+ struct extcon_specific_cable_nb extcon_vbus_dev;
+ struct extcon_specific_cable_nb extcon_id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+
+ struct regulator*vbus_reg;
};
-static struct dwc3_omap*_omap;
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_VBUS_OFF,
+ OMAP_DWC3_VBUS_VALID,
+};
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
@@ -221,18 +235,24 @@ static void dwc3_omap_write_irq0_set(struct dwc3_omap
*omap, u32 value)
omap->irq0_offset, value);
}
-int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
+ enum omap_dwc3_vbus_id_status status)
{
- u32 val;
- struct dwc3_omap*omap = _omap;
-
- if (!omap)
- return -EPROBE_DEFER;
+ int ret;
+ u32 val;
switch (status) {
case OMAP_DWC3_ID_GROUND:
dev_dbg(omap->dev, "ID GND\n");
+ if (omap->vbus_reg) {
+ ret = regulator_enable(omap->vbus_reg);
+ if (ret) {
+ dev_dbg(omap->dev, "regulator enable failed\n");
+ return;
+ }
+ }
+
val = dwc3_omap_read_utmi_status(omap);
val &= ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
| USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
@@ -255,6 +275,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
case OMAP_DWC3_ID_FLOAT:
+ if (omap->vbus_reg)
+
[PATCH 1/4] arm: omap5: dts: fix reg property size
USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.
Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..5c99f19 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -637,7 +637,7 @@
omap_dwc3@4a02 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss";
- reg = <0x4a02 0x1000>;
+ reg = <0x4a02 0x1>;
interrupts = ;
#address-cells = <1>;
#size-cells = <1>;
@@ -645,7 +645,7 @@
ranges;
dwc3@4a03 {
compatible = "synopsys,dwc3";
- reg = <0x4a03 0x1000>;
+ reg = <0x4a03 0x1>;
interrupts = ;
usb-phy = <&usb2_phy>, <&usb3_phy>;
tx-fifo-resize;
--
1.8.2.1
--
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 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
From: Benoit Cousson
without that hwmod data, USB3 will not in OMAP5 boards.
While at that, also fix DTS data to pass reg property,
otherwise driver won't probe.
Signed-off-by: Benoit Cousson
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/omap5.dtsi | 3 +-
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5c99f19..4e41409 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -652,10 +652,11 @@
};
};
- ocp2scp {
+ ocp2scp@4a08 {
compatible = "ti,omap-ocp2scp";
#address-cells = <1>;
#size-cells = <1>;
+ reg = <0x4a08 0x20>;
ranges;
ti,hwmods = "ocp2scp1";
usb2_phy: usb2phy@4a084000 {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..542eddd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1114,6 +1114,42 @@ static struct omap_hwmod omap54xx_mpu_hwmod = {
};
/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_ocp2scp_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_ocp2scp_hwmod_class = {
+ .name = "ocp2scp",
+ .sysc = &omap54xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod omap54xx_ocp2scp1_hwmod = {
+ .name = "ocp2scp1",
+ .class = &omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'timer' class
* general purpose timer module with accurate 1ms tick
* This class contains several variants: ['timer_1ms', 'timer']
@@ -1919,6 +1955,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> ocp2scp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp1 = {
+ .master = &omap54xx_l4_cfg_hwmod,
+ .slave = &omap54xx_ocp2scp1_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_wkup -> timer1 */
static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
.master = &omap54xx_l4_wkup_hwmod,
@@ -2121,6 +2165,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
&omap54xx_l4_per__mmc4,
&omap54xx_l4_per__mmc5,
&omap54xx_l4_cfg__mpu,
+ &omap54xx_l4_cfg__ocp2scp1,
&omap54xx_l4_wkup__timer1,
&omap54xx_l4_per__timer2,
&omap54xx_l4_per__timer3,
--
1.8.2.1
--
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 3/4] arm: omap5: dts: add palmas-usb node
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/omap5-uevm.dts | 10 ++
arch/arm/boot/dts/omap5.dtsi | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..badceb8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -272,6 +272,11 @@
interrupt-controller;
#interrupt-cells = <2>;
+ extcon_usb3: palmas_usb {
+ compatible = "ti,palmas-usb";
+ ti,wakeup;
+ };
+
palmas_pmic {
compatible = "ti,palmas-pmic";
interrupt-parent = <&palmas>;
@@ -450,6 +455,11 @@
phys = <0 &hsusb2_phy &hsusb3_phy>;
};
+&usb3 {
+ extcon = <&extcon_usb3>;
+ vbus-supply = <&smps10_reg>;
+};
+
&mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
ti,type = <2>;
};
- omap_dwc3@4a02 {
+ usb3: omap_dwc3@4a02 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss";
reg = <0x4a02 0x1>;
--
1.8.2.1
--
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 0/4] Enable USB3 for OMAP5
Hi,
I have just tested all these patches on OMAP5 uEVM and it's
working fine.
| [1141397.137900] usb 10-2: USB disconnect, device number 3
| [1142023.549485] usb 10-2: new SuperSpeed USB device number 4 using xhci_hcd
| [1142024.185535] usb 10-2: Parent hub missing LPM exit latency info. Power
management will be impacted.
| [1142025.458738] usb 10-2: New USB device found, idVendor=0525, idProduct=a4a0
| [1142025.458744] usb 10-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
| [1142025.458748] usb 10-2: Product: Gadget Zero
| [1142025.458752] usb 10-2: Manufacturer: Linux
3.11.0-rc1-00068-g6df6cd3-dirty with dwc3-gadget
| [1142025.458755] usb 10-2: SerialNumber: 0123456789.0123456789.0123456789
| [1142025.866540] usbtest 10-2:3.0: Linux gadget zero
| [1142025.866547] usbtest 10-2:3.0: super-speed {control in/out bulk-in
bulk-out} tests (+alt)
please consider applying them.
Benoit Cousson (1):
arm: omap5: hwmod: add missing ocp2scp hwmod data
Felipe Balbi (3):
arm: omap5: dts: fix reg property size
arm: omap5: dts: add palmas-usb node
arm: omap2plus_defconfig: enable dwc3 and dependencies
arch/arm/boot/dts/omap5-uevm.dts | 10 +++
arch/arm/boot/dts/omap5.dtsi | 9 +++---
arch/arm/configs/omap2plus_defconfig | 9 ++
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++
4 files changed, 69 insertions(+), 4 deletions(-)
--
1.8.2.1
--
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 4/4] arm: omap2plus_defconfig: enable dwc3 and dependencies
DWC3 enables USB3 functionality for OMAP5 boards, it's safe to enable those drivers in omap2plus_defconfig. Signed-off-by: Felipe Balbi --- arch/arm/configs/omap2plus_defconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 5339e6a..aed3cce 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -81,6 +81,7 @@ CONFIG_CMA=y CONFIG_CONNECTOR=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_OMAP_OCP2SCP=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y @@ -167,9 +168,11 @@ CONFIG_THERMAL_GOV_USER_SPACE=y CONFIG_CPU_THERMAL=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y +CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y @@ -222,10 +225,14 @@ CONFIG_USB_MON=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y +CONFIG_USB_DWC3=m +CONFIG_USB_DWC3_OMAP=m CONFIG_USB_TEST=y CONFIG_USB_PHY=y CONFIG_NOP_USB_XCEIV=y CONFIG_USB_GADGET=y +CONFIG_OMAP_USB2=y +CONFIG_OMAP_USB3=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y CONFIG_USB_GADGET_DEBUG_FS=y @@ -258,6 +265,8 @@ CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y +CONFIG_EXTCON=y +CONFIG_EXTCON_PALMAS=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set -- 1.8.2.1 -- 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] typo fixes (coordiante -> coordinate) in am335x
Did a grep for coordiante and replaced them all
with coordinate.
This applies to the mfd-next tree.
Signed-off-by: Zubair Lutfullah
---
.../bindings/input/touchscreen/ti-tsc-adc.txt |4 ++--
arch/arm/boot/dts/am335x-evm.dts |2 +-
drivers/input/touchscreen/ti_am335x_tsc.c |2 +-
drivers/mfd/ti_am335x_tscadc.c |2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 491c97b..3e22aec 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -6,7 +6,7 @@ Required properties:
ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
support on the platform.
ti,x-plate-resistance: X plate resistance
- ti,coordiante-readouts: The sequencer supports a total of 16
+ ti,coordinate-readouts: The sequencer supports a total of 16
programmable steps each step is used to
read a single coordinate. A single
readout is enough but multiple reads can
@@ -34,7 +34,7 @@ Example:
tsc {
ti,wires = <4>;
ti,x-plate-resistance = <200>;
- ti,coordiante-readouts = <5>;
+ ti,coordinate-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0fa4c7f..e50b781 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -250,7 +250,7 @@
tsc {
ti,wires = <4>;
ti,x-plate-resistance = <200>;
- ti,coordiante-readouts = <5>;
+ ti,coordinate-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
};
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 0e9f02a..6422f65 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -348,7 +348,7 @@ static int titsc_parse_dt(struct platform_device *pdev,
if (err < 0)
return err;
- err = of_property_read_u32(node, "ti,coordiante-readouts",
+ err = of_property_read_u32(node, "ti,coordinate-readouts",
&ts_dev->coordinate_readouts);
if (err < 0)
return err;
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index b003a16..dd31e23 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -106,7 +106,7 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
node = of_get_child_by_name(pdev->dev.of_node, "tsc");
of_property_read_u32(node, "ti,wires", &tsc_wires);
- of_property_read_u32(node, "ti,coordiante-readouts", &readouts);
+ of_property_read_u32(node, "ti,coordinate-readouts", &readouts);
node = of_get_child_by_name(pdev->dev.of_node, "adc");
of_property_for_each_u32(node, "ti,adc-channels", prop, cur, val) {
--
1.7.9.5
--
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 v1 5/5] mtd: nand: omap: code clean-up and white-space fixes
This patch just clean-up the code and fixes spaces in omap_nand_probe()
s/info->nand./chip->
s/&info->mtd/mtd
Signed-off-by: Pekon Gupta
---
drivers/mtd/nand/omap2.c | 210 +++
1 file changed, 102 insertions(+), 108 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7d786d9..c2c3c6bb 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1462,9 +1462,9 @@ static int omap_nand_probe(struct platform_device *pdev)
info->reg = pdata->reg;
info->ecc_opt = pdata->ecc_opt;
- info->nand.options = NAND_BUSWIDTH_AUTO;
- info->nand.options |= NAND_SKIP_BBTSCAN;
- info->nand.ecc.priv = NULL;
+ chip->options = NAND_BUSWIDTH_AUTO;
+ chip->options |= NAND_SKIP_BBTSCAN;
+ chip->ecc.priv = NULL;
#ifdef CONFIG_MTD_NAND_OMAP_BCH
info->of_node = pdata->of_node;
#endif
@@ -1485,16 +1485,16 @@ static int omap_nand_probe(struct platform_device *pdev)
goto out_free_info;
}
- info->nand.IO_ADDR_R = ioremap(info->phys_base, info->mem_size);
- if (!info->nand.IO_ADDR_R) {
+ chip->IO_ADDR_R = ioremap(info->phys_base, info->mem_size);
+ if (!chip->IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
}
- info->nand.controller = &info->controller;
+ chip->controller = &info->controller;
- info->nand.IO_ADDR_W = info->nand.IO_ADDR_R;
- info->nand.cmd_ctrl = omap_hwcontrol;
+ chip->IO_ADDR_W = chip->IO_ADDR_R;
+ chip->cmd_ctrl = omap_hwcontrol;
/*
* If RDY/BSY line is connected to OMAP then use the omap ready
@@ -1504,11 +1504,11 @@ static int omap_nand_probe(struct platform_device *pdev)
* device and read status register until you get a failure or success
*/
if (pdata->dev_ready) {
- info->nand.dev_ready = omap_dev_ready;
- info->nand.chip_delay = 0;
+ chip->dev_ready = omap_dev_ready;
+ chip->chip_delay = 0;
} else {
- info->nand.waitfunc = omap_wait;
- info->nand.chip_delay = 50;
+ chip->waitfunc = omap_wait;
+ chip->chip_delay = 50;
}
/* scan NAND device conncted to controller */
@@ -1517,8 +1517,8 @@ static int omap_nand_probe(struct platform_device *pdev)
goto out_release_mem_region;
}
pr_info("%s: detected %s NAND flash\n", DRIVER_NAME,
- (info->nand.options & NAND_BUSWIDTH_16) ? "x16" : "x8");
- if ((info->nand.options & NAND_BUSWIDTH_16) !=
+ (chip->options & NAND_BUSWIDTH_16) ? "x16" : "x8");
+ if ((chip->options & NAND_BUSWIDTH_16) !=
(pdata->devsize & NAND_BUSWIDTH_16)) {
pr_err("%s: but incorrectly configured as %s", DRIVER_NAME,
(pdata->devsize & NAND_BUSWIDTH_16) ? "x16" : "x8");
@@ -1538,17 +1538,17 @@ static int omap_nand_probe(struct platform_device *pdev)
/* populate read & write API based on xfer_type selected */
switch (pdata->xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
- info->nand.read_buf = omap_read_buf_pref;
- info->nand.write_buf = omap_write_buf_pref;
+ chip->read_buf = omap_read_buf_pref;
+ chip->write_buf = omap_write_buf_pref;
break;
case NAND_OMAP_POLLED:
- if (info->nand.options & NAND_BUSWIDTH_16) {
- info->nand.read_buf = omap_read_buf16;
- info->nand.write_buf = omap_write_buf16;
+ if (chip->options & NAND_BUSWIDTH_16) {
+ chip->read_buf = omap_read_buf16;
+ chip->write_buf = omap_write_buf16;
} else {
- info->nand.read_buf = omap_read_buf8;
- info->nand.write_buf = omap_write_buf8;
+ chip->read_buf = omap_read_buf8;
+ chip->write_buf = omap_write_buf8;
}
break;
@@ -1577,8 +1577,8 @@ static int omap_nand_probe(struct platform_device *pdev)
err);
goto out_release_mem_region;
}
- info->nand.read_buf = omap_read_buf_dma_pref;
- info->nand.write_buf = omap_write_buf_dma_pref;
+ chip->read_buf = omap_read_buf_dma_pref;
+ chip->write_buf = omap_write_buf_dma_pref;
}
break;
@@ -1613,8 +1613,8 @@ static int omap_nand_probe(struct platform_device *pdev)
goto out_release_mem_region;
}
- info->
[PATCH v1 1/5] mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemes
chip->ecc.correct() is used for detecting and correcting bit-flips during read
operations. In omap2-nand driver this is done usingt following functions:
- omap_correct_data(): for H/W based HAM1_ECC schemes
(Un-Touched in current patch)
- omap_elm_correct_data(): for H/W based BCHx_ECC scheme
Current implementation of this function is not scalable for newer ECC
schemes because:
- It depends on a specific byte-position in OOB area (reserved as 0x00)
to differentiates between programmed-pages and erased-pages.
This reserved byte-position cannot be accomodated in all ECC schemes.
- Current code is not scalable for future ECC schemes due to tweaks for
BCH4_ECC and BCH8_ECC at multiple places.
- It checks for bit-flips in Erased-pages using check_erased_page().
This is over-work, as sanity of Erased-page can be verified by just
comparing them to a pre-defined ECC-syndrome for all_0xFF data.
This patch optimizes omap_elm_correct_data() in following ways:
(1) Removes dependency on specific reserved-byte (0x00) in OOB area,
instead Erased-page is identified by matching calc_ecc with a
pre-defined ECC syndrome of all(0xFF) data
(2) merges common code for BCH4_ECC and BCH8_ECC for scalability.
(3) handles incorrect elm_error_location beyond data+oob buffer.
(4) removes check_erased_page(): Bit-flips in erased-page are handled
in same way as for programmed-page
Signed-off-by: Pekon Gupta
---
drivers/mtd/nand/omap2.c | 249 ++-
1 file changed, 75 insertions(+), 174 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index e9ef743..5321bdcc 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -176,6 +176,7 @@ struct omap_nand_info {
int gpmc_cs;
unsigned long phys_base;
unsigned long mem_size;
+ enum omap_ecc ecc_opt;
struct completion comp;
struct dma_chan *dma;
int gpmc_irq_fifo;
@@ -1307,219 +1308,118 @@ static int omap3_calculate_ecc_bch(struct mtd_info
*mtd, const u_char *dat,
}
/**
- * erased_sector_bitflips - count bit flips
- * @data: data sector buffer
- * @oob: oob buffer
- * @info: omap_nand_info
- *
- * Check the bit flips in erased page falls below correctable level.
- * If falls below, report the page as erased with correctable bit
- * flip, else report as uncorrectable page.
- */
-static int erased_sector_bitflips(u_char *data, u_char *oob,
- struct omap_nand_info *info)
-{
- int flip_bits = 0, i;
-
- for (i = 0; i < info->nand.ecc.size; i++) {
- flip_bits += hweight8(~data[i]);
- if (flip_bits > info->nand.ecc.strength)
- return 0;
- }
-
- for (i = 0; i < info->nand.ecc.bytes - 1; i++) {
- flip_bits += hweight8(~oob[i]);
- if (flip_bits > info->nand.ecc.strength)
- return 0;
- }
-
- /*
-* Bit flips falls in correctable level.
-* Fill data area with 0xFF
-*/
- if (flip_bits) {
- memset(data, 0xFF, info->nand.ecc.size);
- memset(oob, 0xFF, info->nand.ecc.bytes);
- }
-
- return flip_bits;
-}
-
-/**
* omap_elm_correct_data - corrects page data area in case error reported
* @mtd: MTD device structure
* @data: page data
* @read_ecc: ecc read from nand flash
- * @calc_ecc: ecc read from HW ECC registers
- *
- * Calculated ecc vector reported as zero in case of non-error pages.
- * In case of error/erased pages non-zero error vector is reported.
- * In case of non-zero ecc vector, check read_ecc at fixed offset
- * (x = 13/7 in case of BCH8/4 == 0) to find page programmed or not.
- * To handle bit flips in this data, count the number of 0's in
- * read_ecc[x] and check if it greater than 4. If it is less, it is
- * programmed page, else erased page.
- *
- * 1. If page is erased, check with standard ecc vector (ecc vector
- * for erased page to find any bit flip). If check fails, bit flip
- * is present in erased page. Count the bit flips in erased page and
- * if it falls under correctable level, report page with 0xFF and
- * update the correctable bit information.
- * 2. If error is reported on programmed page, update elm error
- * vector and correct the page with ELM error correction routine.
- *
+ * @calc_ecc: ecc calculated after reading Data and OOB regions from flash
+ * As calc_ecc is calculated over both main & oob, so calc_ecc would be
+ * non-zero only in following cases:
+ * - bit-flips in data or oob region
+ * - erase page, where no ECC is written in OOB area
+ * However, erased_page
[PATCH v1 0/5] optimize and clean-up of OMAP NAND and ELM driver
This patch series builds the base for adding support for newer H/W based ECC schemes for NAND flash. This patch cleans-up redundant code among various ECC schemes and improves scalability and readability. This patch affects following data-paths: [PATCH 1/5] NAND chip->ecc.correct(): Detects and corrects ECC errors on read accesses. [PATCH 2/5] NAND chip->ecc.calculate(): Calculates and fetches ECC syndrome from controller. [PATCH 3/5] NAND chip->ecc.hwctl(): Configures H/W controller for Read/Write data acccesses. [PATCH 4/5] ELM add checks and updates code for scalability. [PATCH 5/5] NAND code clean-up to improve readability. Pekon Gupta (5): mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemes mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemes mtd: nand: omap: optimize chip->ecc.hwctl() for H/W ECC schemes mtd: devices: elm: add checks ELM H/W constrains, driver code cleanup mtd: nand: omap: code clean-up and white-space fixes drivers/mtd/devices/elm.c | 114 ++--- drivers/mtd/nand/omap2.c | 906 ++ include/linux/platform_data/elm.h | 6 +- 3 files changed, 411 insertions(+), 615 deletions(-) -- 1.8.1 -- 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 v1 4/5] mtd: devices: elm: add checks ELM H/W constrains, driver code cleanup
ELM H/W engine is used by BCHx_ECC schemes for detecting and locating bit-flips.
However, ELM H/W engine has some constrains like:
- ELM can decode errors in chunks of 512 data bytes only
- ELM can operate max upto 8 such buffers in parallel
This patch
- add checks for above constrains
- fixes ELM register configs based on number of info->eccsteps
- cleans-up elm_load_syndrome()
Signed-off-by: Pekon Gupta
---
drivers/mtd/devices/elm.c | 114 ++
drivers/mtd/nand/omap2.c | 2 +-
include/linux/platform_data/elm.h | 6 +-
3 files changed, 70 insertions(+), 52 deletions(-)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index 4f683d2..fca436e 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -22,8 +22,11 @@
#include
#include
#include
+#include
+#include
#include
+#defineDRIVER_NAME "omap-elm"
#define ELM_SYSCONFIG 0x010
#define ELM_IRQSTATUS 0x018
#define ELM_IRQENABLE 0x01c
@@ -82,8 +85,10 @@ struct elm_info {
void __iomem *elm_base;
struct completion elm_completion;
struct list_head list;
+ struct mtd_info *mtd;
enum bch_ecc bch_type;
struct elm_registers elm_regs;
+ int eccsteps;
};
static LIST_HEAD(elm_devices);
@@ -103,19 +108,36 @@ static u32 elm_read_reg(struct elm_info *info, int offset)
* @dev: ELM device
* @bch_type: Type of BCH ecc
*/
-int elm_config(struct device *dev, enum bch_ecc bch_type)
+int elm_config(struct device *dev, struct mtd_info *mtd,
+ enum bch_ecc bch_type)
{
u32 reg_val;
- struct elm_info *info = dev_get_drvdata(dev);
-
+ struct elm_info *info = dev_get_drvdata(dev);
+ struct nand_chip *chip = mtd->priv;
if (!info) {
dev_err(dev, "Unable to configure elm - device not probed?\n");
return -ENODEV;
}
-
+ if (!mtd) {
+ pr_err("%s: MTD device not found", DRIVER_NAME);
+ return -EINVAL;
+ }
+ /* ELM supports error correction in chunks of 512bytes of data only
+* where each 512bytes of data has its own ECC syndrome */
+ if (chip->ecc.size != 512) {
+ pr_err("%s: invalid ecc_size configuration", DRIVER_NAME);
+ return -EINVAL;
+ }
+ /* ELM eccsteps required to decode complete NAND page */
+ info->eccsteps = mtd->writesize / chip->ecc.size;
+ if (info->eccsteps > 8) {
+ pr_err("%s: eccsteps > 8 are not supported", DRIVER_NAME);
+ return -EINVAL;
+ }
+ info->mtd = mtd;
+ info->bch_type = bch_type;
reg_val = (bch_type & ECC_BCH_LEVEL_MASK) | (ELM_ECC_SIZE << 16);
elm_write_reg(info, ELM_LOCATION_CONFIG, reg_val);
- info->bch_type = bch_type;
return 0;
}
@@ -152,55 +174,51 @@ static void elm_configure_page_mode(struct elm_info
*info, int index,
* Load syndrome fragment registers with calculated ecc in reverse order.
*/
static void elm_load_syndrome(struct elm_info *info,
- struct elm_errorvec *err_vec, u8 *ecc)
+ struct elm_errorvec *err_vec, u8 *ecc_calc)
{
+ struct nand_chip *chip = info->mtd->priv;
+ unsigned int eccbytes = chip->ecc.bytes;
+ u8 *ecc = ecc_calc;
int i, offset;
u32 val;
- for (i = 0; i < ERROR_VECTOR_MAX; i++) {
-
+ for (i = 0; i < info->eccsteps; i++) {
/* Check error reported */
if (err_vec[i].error_reported) {
elm_configure_page_mode(info, i, true);
- offset = ELM_SYNDROME_FRAGMENT_0 +
- SYNDROME_FRAGMENT_REG_SIZE * i;
-
- /* BCH8 */
- if (info->bch_type) {
-
- /* syndrome fragment 0 = ecc[9-12B] */
- val = cpu_to_be32(*(u32 *) &ecc[9]);
- elm_write_reg(info, offset, val);
-
- /* syndrome fragment 1 = ecc[5-8B] */
- offset += 4;
- val = cpu_to_be32(*(u32 *) &ecc[5]);
- elm_write_reg(info, offset, val);
-
- /* syndrome fragment 2 = ecc[1-4B] */
- offset += 4;
- val = cpu_to_be32(*(u32 *) &ecc[1]);
- elm_write_reg(info, offset, val);
-
- /* syndrome fragment 3 = ecc[0B] */
- offset += 4;
- val = ecc[0];
- elm_write_reg(info, offset, val);
- } else {
- /* syndrome fragment 0 = ecc[20-52b] bits */
-
[PATCH v1 2/5] mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemes
chip->ecc.calculate() is used for calculating and fetching of ECC syndrome by
processing the data passed during Read/Write accesses.
All H/W based ECC schemes supported in omap2-nand driver use GPMC controller
to calculate ECC syndrome. But each BCHx_ECC scheme implements its own function
to process and fetch ECC syndrom from GPMC controller.
This patch tries to merges the common code for different BCHx_ECC schemes into
single omap_calculate_ecc_bch(), And adds schemes specific post-possessing
after fetching ECC-syndrome. This removes redundant code and adds scalability
for future ECC-schemes. This patch:
- [un-touched] omap_calculate_ecc(): Used for HAM1_ECC
- [merged] omap3_calculate_ecc_bch4(): Used for BCH4_HW_DETECTION_SW
- [merged] omap3_calculate_ecc_bch8(): Used for BCH8_HW_DETECTION_SW
- [merged] omap3_calculate_ecc_bch(): Used for BCH4_HW and BCH8_HW
- [new] omap_calculate_ecc_bch(): Now used for all BCHx_ECC
Signed-off-by: Pekon Gupta
---
drivers/mtd/nand/omap2.c | 249 ++-
1 file changed, 95 insertions(+), 154 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5321bdcc..7f7a2ee 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -151,7 +151,9 @@ static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16,
0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 0x41, 0xbc, 0x10};
#endif
-
+static u8 bch4_polynomial[] = {0x28, 0x13, 0xcc, 0x39, 0x96, 0xac, 0x7f};
+static u8 bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09, 0xed, 0x93, 0x9a, 0xc2,
+ 0x97, 0x79, 0xe5, 0x24, 0xb5};
/* oob info generated runtime depending on ecc algorithm and layout selected */
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -950,9 +952,11 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
u_char *dat,
u32 val;
val = readl(info->reg.gpmc_ecc_config);
- if (((val >> ECC_CONFIG_CS_SHIFT) & ~CS_MASK) != info->gpmc_cs)
+ if (((val >> 1) & 0x07) != info->gpmc_cs) {
+ pr_err("%s: invalid ECC configuration for chip-select=%d",
+ DRIVER_NAME, info->gpmc_cs);
return -EINVAL;
-
+ }
/* read ecc result */
val = readl(info->reg.gpmc_ecc1_result);
*ecc_code++ = val; /* P128e, ..., P1e */
@@ -1141,172 +1145,109 @@ static void omap3_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
writel(ECCCLEAR | ECC1, info->reg.gpmc_ecc_control);
}
-#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
- * omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
- * @mtd: MTD device structure
- * @dat: The pointer to data on which ecc is computed
- * @ecc_code: The ecc_code buffer
- */
-static int omap3_calculate_ecc_bch4(struct mtd_info *mtd, const u_char *dat,
- u_char *ecc_code)
-{
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
- unsigned long nsectors, val1, val2;
- int i;
-
- nsectors = ((readl(info->reg.gpmc_ecc_config) >> 4) & 0x7) + 1;
-
- for (i = 0; i < nsectors; i++) {
-
- /* Read hw-computed remainder */
- val1 = readl(info->reg.gpmc_bch_result0[i]);
- val2 = readl(info->reg.gpmc_bch_result1[i]);
-
- /*
-* Add constant polynomial to remainder, in order to get an ecc
-* sequence of 0xFFs for a buffer filled with 0xFFs; and
-* left-justify the resulting polynomial.
-*/
- *ecc_code++ = 0x28 ^ ((val2 >> 12) & 0xFF);
- *ecc_code++ = 0x13 ^ ((val2 >> 4) & 0xFF);
- *ecc_code++ = 0xcc ^ (((val2 & 0xF) << 4)|((val1 >> 28) & 0xF));
- *ecc_code++ = 0x39 ^ ((val1 >> 20) & 0xFF);
- *ecc_code++ = 0x96 ^ ((val1 >> 12) & 0xFF);
- *ecc_code++ = 0xac ^ ((val1 >> 4) & 0xFF);
- *ecc_code++ = 0x7f ^ ((val1 & 0xF) << 4);
- }
-
- return 0;
-}
-
-/**
- * omap3_calculate_ecc_bch8 - Generate 13 bytes of ECC bytes
- * @mtd: MTD device structure
- * @dat: The pointer to data on which ecc is computed
- * @ecc_code: The ecc_code buffer
- */
-static int omap3_calculate_ecc_bch8(struct mtd_info *mtd, const u_char *dat,
- u_char *ecc_code)
-{
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
- unsigned long nsectors, val1, val2, val3, val4;
- int i;
-
- nsectors = ((readl(info->reg.gpmc_ecc_config) >> 4) & 0x7) + 1;
-
- for (i = 0; i < nsectors; i++) {
-
- /* Read hw-computed remainder */
-
[PATCH v1 3/5] mtd: nand: omap: optimize chip->ecc.hwctl() for H/W ECC schemes
chip->ecc.hwctl() is used for preparing the H/W controller before read/write
NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.)
Though all ECC schemes in OMAP NAND driver use GPMC controller for generating
ECC syndrome (for both Read/Write accesses). But but in current code
HAM1_ECC and BCHx_ECC schemes implement individual function to achieve this.
This patch merges the GPMC configuration code for all ECC schemes into
single omap_enable_hwecc(), thus adding scalability for future ECC schemes.
omap_enable_hwecc() + omap3_enable_hwecc_bch() -> omap_enable_hwecc()
Signed-off-by: Pekon Gupta
---
drivers/mtd/nand/omap2.c | 216 +--
1 file changed, 79 insertions(+), 137 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7f7a2ee..a259761 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -38,6 +38,10 @@
#defineDRIVER_NAME "omap2-nand"
#defineOMAP_NAND_TIMEOUT_MS5000
+#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
+#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
+#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */
+
#define NAND_Ecc_P1e (1 << 0)
#define NAND_Ecc_P2e (1 << 1)
#define NAND_Ecc_P4e (1 << 2)
@@ -106,13 +110,9 @@
#define P4o_s(a) (TF(a & NAND_Ecc_P4o) << 1)
#definePREFETCH_CONFIG1_CS_SHIFT 24
-#defineECC_CONFIG_CS_SHIFT 1
#defineCS_MASK 0x7
#defineENABLE_PREFETCH (0x1 << 7)
#defineDMA_MPU_MODE_SHIFT 2
-#defineECCSIZE0_SHIFT 12
-#defineECCSIZE1_SHIFT 22
-#defineECC1RESULTSIZE 0x1
#defineECCCLEAR0x100
#defineECC10x1
#definePREFETCH_FIFOTHRESHOLD_MAX 0x40
@@ -123,26 +123,9 @@
#define OMAP24XX_DMA_GPMC 4
-#define BCH8_MAX_ERROR 8 /* upto 8 bit correctable */
-#define BCH4_MAX_ERROR 4 /* upto 4 bit correctable */
-
#define SECTOR_BYTES 512
/* 4 bit padding to make byte aligned, 56 = 52 + 4 */
#define BCH4_BIT_PAD 4
-#define BCH8_ECC_MAX ((SECTOR_BYTES + BCH8_ECC_OOB_BYTES) * 8)
-#define BCH4_ECC_MAX ((SECTOR_BYTES + BCH4_ECC_OOB_BYTES) * 8)
-
-/* GPMC ecc engine settings for read */
-#define BCH_WRAPMODE_1 1 /* BCH wrap mode 1 */
-#define BCH8R_ECC_SIZE00x1a/* ecc_size0 = 26 */
-#define BCH8R_ECC_SIZE10x2 /* ecc_size1 = 2 */
-#define BCH4R_ECC_SIZE00xd /* ecc_size0 = 13 */
-#define BCH4R_ECC_SIZE10x3 /* ecc_size1 = 3 */
-
-/* GPMC ecc engine settings for write */
-#define BCH_WRAPMODE_6 6 /* BCH wrap mode 6 */
-#define BCH_ECC_SIZE0 0x0 /* ecc_size0 = 0, no oob protection */
-#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
#define BADBLOCK_MARKER_LENGTH 0x2
@@ -191,7 +174,6 @@ struct omap_nand_info {
int buf_len;
struct gpmc_nand_regs reg;
/* fields specific for BCHx_HW ECC scheme */
- boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
};
@@ -952,7 +934,7 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
u_char *dat,
u32 val;
val = readl(info->reg.gpmc_ecc_config);
- if (((val >> 1) & 0x07) != info->gpmc_cs) {
+ if (((val >> 1) & 0x7) != info->gpmc_cs) {
pr_err("%s: invalid ECC configuration for chip-select=%d",
DRIVER_NAME, info->gpmc_cs);
return -EINVAL;
@@ -968,47 +950,6 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
u_char *dat,
}
/**
- * omap_enable_hwecc - This function enables the hardware ecc functionality
- * @mtd: MTD device structure
- * @mode: Read/Write mode
- */
-static void omap_enable_hwecc(struct mtd_info *mtd, int mode)
-{
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
- struct nand_chip *chip = mtd->priv;
- unsigned int dev_width = (chip->options & NAND_BUSWIDTH_16) ? 1 : 0;
- u32 val;
-
- /* clear ecc and enable bits */
- val = ECCCLEAR | ECC1;
- writel(val, info->reg.gpmc_ecc_control);
-
- /* program ecc and result sizes */
- val = info->nand.ecc.size >> 1) - 1) << ECCSIZE1_SHIFT) |
-ECC1RESULTSIZE);
- writel(val, info->reg.gpmc_ecc_size_config);
-
- switch (mode) {
- case NAND_ECC_READ:
- case NAND_ECC_WRITE:
- writel(ECCCLEAR | ECC1,
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
Hi Tony,
On 06/18/2013 07:04 PM, Roger Quadros wrote:
> Till the OMAP clocks are correctly defined in device tree, use
> this temporary hack to provide clock alias to the USB PHY clocks.
>
> Without this, USB Host & Ethernet will not be functional with
> device tree boots on Panda and uEVM.
Looks like this one got missed out.
USB host no longer works on Panda with DT boot.
Could you please queue this for next 3.11-rc? Thanks.
cheers,
-roger
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/board-generic.c | 23 ++-
> 1 files changed, 22 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 88aa6b1..7428733 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -35,6 +36,21 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = {
> { }
> };
>
> +/*
> + * Create alias for USB host PHY clock.
> + * Remove this when clock phandle can be provided via DT
> + */
> +static void __init legacy_init_ehci_clk(char *clkname)
> +{
> + int ret;
> +
> + ret = clk_add_alias("main_clk", NULL, clkname, NULL);
> + if (ret) {
> + pr_err("%s:Failed to add main_clk alias to %s :%d\n",
> + __func__, clkname, ret);
> + }
> +}
> +
> static void __init omap_generic_init(void)
> {
> omap_sdrc_init(NULL, NULL);
> @@ -45,10 +61,15 @@ static void __init omap_generic_init(void)
>* HACK: call display setup code for selected boards to enable omapdss.
>* This will be removed when omapdss supports DT.
>*/
> - if (of_machine_is_compatible("ti,omap4-panda"))
> + if (of_machine_is_compatible("ti,omap4-panda")) {
> omap4_panda_display_init_of();
> + legacy_init_ehci_clk("auxclk3_ck");
> +
> + }
> else if (of_machine_is_compatible("ti,omap4-sdp"))
> omap_4430sdp_display_init_of();
> + else if (of_machine_is_compatible("ti,omap5-uevm"))
> + legacy_init_ehci_clk("auxclk1_ck");
> }
>
> #ifdef CONFIG_SOC_OMAP2420
>
--
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 v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 15/07/13 14:30, Kozaruk, Oleksandr wrote:
> Hello Jonathan,
> Thanks for the review.
>
>> Couple of things:
>>
>> 1) It looks from the driver that a lot of the channels are not measuring
>> voltages but rather temperature or currents etc. If so then their
>> types in the channel mask should be appropriately set. Also if some
>> of the channels are entirely internal test networks, what is the benefit
>> of exposing them to userspace as readable channels?
>> If channels are merely 'suggested' as being used for temperatures etc
>> then it is fine to keep them as voltages.
> There are two kinds of channel for measuring temperature: die temperature
> and those that measure temperature indirectly measuring voltage on resistive
> load(NTC sensor).
> die temperature is calculated by some formulas which convert ADC code to
> temperature. This is not implemented in the driver.
> Channels intended to measure temperature with NTC sensor have inbuilt current
> sources. Voltage measured by this channels and specific NTC could be converted
> to temperature.
> This is the reason they chosen to be voltage channels.
> As for test network I'll remove them from exposing to userspace.
> [...]
>
>>> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>>> + int channel, int *res)
>>> +{
>>> + u8 reg = gpadc->pdata->channel_to_reg(channel);
>>> + u8 val[2];
>> le16 val;
>>> + int ret;
>>> +
>> ret = twl6030_gpadc_read(val, reg);
>> (note that (reg, val) ordering of parameters would be a more common choice)
>>
>>> + ret = twl6030_gpadc_read(val, reg);
>>> + if (ret) {
>>> + dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>>> + return ret;
>>> + }
>>> +
>> res = le16_to_cpup(val);
>>
>>> + *res = (val[1] << 8) | val[0];
>>> +
>>> + return ret;
>>> +}
>>> +
> You mean something like this:
> static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>
>
> int channel, int *res)
>
>
>
> {
>
>
> u8 reg = gpadc->pdata->channel_to_reg(channel);
>
>
> __le16 val;
>
>
> int ret;
>
>
>
> ret = twl6030_gpadc_read(reg, (u8 *)&val);
>
>
> if (ret) {
>
>
> dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>
>
> return ret;
>
>
> }
>
>
>
> *res = le16_to_cpup(&val);
>
>
>
> return ret;
>
>
> }
> Note, that twl6030_gpadc_read() is just wrapper for twl_i2c_read() which takes
> "an array of num_bytes containing data to be read"
> I like the original implementation better then this(if I did it correctly
RE: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Jonathan,
Thanks for the review.
>Couple of things:
>
>1) It looks from the driver that a lot of the channels are not measuring
>voltages but rather temperature or currents etc. If so then their
>types in the channel mask should be appropriately set. Also if some
>of the channels are entirely internal test networks, what is the benefit
>of exposing them to userspace as readable channels?
>If channels are merely 'suggested' as being used for temperatures etc
>then it is fine to keep them as voltages.
There are two kinds of channel for measuring temperature: die temperature
and those that measure temperature indirectly measuring voltage on resistive
load(NTC sensor).
die temperature is calculated by some formulas which convert ADC code to
temperature. This is not implemented in the driver.
Channels intended to measure temperature with NTC sensor have inbuilt current
sources. Voltage measured by this channels and specific NTC could be converted
to temperature.
This is the reason they chosen to be voltage channels.
As for test network I'll remove them from exposing to userspace.
[...]
>> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>> + int channel, int *res)
>> +{
>> + u8 reg = gpadc->pdata->channel_to_reg(channel);
>> + u8 val[2];
>
>le16 val;
>> + int ret;
>> +
>ret = twl6030_gpadc_read(val, reg);
>(note that (reg, val) ordering of parameters would be a more common choice)
>
>> + ret = twl6030_gpadc_read(val, reg);
>> + if (ret) {
>> + dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>> + return ret;
>> + }
>> +
>res = le16_to_cpup(val);
>
>> + *res = (val[1] << 8) | val[0];
>> +
>> + return ret;
>> +}
>> +
You mean something like this:
static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
int channel, int *res)
{
u8 reg = gpadc->pdata->channel_to_reg(channel);
__le16 val;
int ret;
ret = twl6030_gpadc_read(reg, (u8 *)&val);
if (ret) {
dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
return ret;
}
*res = le16_to_cpup(&val);
return ret;
}
Note, that twl6030_gpadc_read() is just wrapper for twl_i2c_read() which takes
"an array of num_bytes containing data to be read"
I like the original implementation better then this(if I did it correctly)
Do you insist on this change?
[...]
>> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
>> + int channel, int *val)
>> +{
>> + int raw_code;
>>
Re: [PATCH] ARM: multi_v7: Enabled omap4430 sdp nfsroot
On Mon, Jul 15, 2013 at 12:58:17AM -0700, Tony Lindgren wrote: > Author: Tony Lindgren > Date: Mon Jul 15 00:39:41 2013 -0700 > > ARM: multi_v7: Enabled omap4430 sdp nfsroot > > By adding support for OCP2SCP, SPI and KS8851 I can also boot test > multi_v7_defconfig easily. > > Note that if using an older u-boot, CONFIG_ARM_ATAG_DTB_COMPAT=y > may also be needed for the appended DTB based booting. > > Signed-off-by: Tony Lindgren We will also use OCP2SCP driver to enable USB3 on OMAP5 uEVM, good it's already enabled in multi_v7 after this patch. Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
Hi Benoit, On 06/20/2013 05:11 PM, Cousson, Benoit wrote: > Thanks Roger, > > I'll take them for 3.12. I was already late for my 3.11 pull request. Please disregard these patches. I'll send a new version based on the reset-gpio driver. cheers, -roger -- 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] remove vlan tags in CPSW dual emac mode
On 7/13/2013 12:55 AM, Mark Jackson wrote: > On 12/07/13 19:35, Mugunthan V N wrote: >> On 7/12/2013 7:27 PM, Mark Jackson wrote: > [snip] > >>> Just to update this (old) thread ... >>> >>> I can still confirm that *without* the above patch, I am *unable* to use >>> both network >>> ports on our AM335x board. >>> > [snip] > >>> So I'm not sure what's wrong, but it's *definitely* not correct. >>> >>> >> I am sure that current code in mainline works for Dual EMAC. I can test it >> again and share the images with you if are interested. But had tested with >> DHCP >> on both the interfaces. > Hmmm ... well it's not working for me. What hardware are you testing it on ? > > I tried DHCP to start with, and switched to static IP when that failed. > Then I recalled this patch and re-applied it ... hey presto !! > > Markus, are you still using this patch ? > Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with net/master branch. I had 3 patches additional to net/master in which two for basic boot of EVMsk and one for enabling Dual EMAC. I had pushed the branch in the below repo repo: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git branch: dual-emac Regards Mugunthan V N -- 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 v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/15/2013 01:56 PM, Grygorii Strashko wrote:
> Hi All,
>
> I have a question regarding this patch and IIO in general
> - Does IIO provide sync mechanism with system wide suspend/resume or this
> should be handled by each driver itself?
>
> What if during system suspend iio_read_channel_raw() (or any other consumer
> API) will be called after gpadc driver have been suspended already? (I did
> some investigation and seems it's possible - Am I right?)
>
> If no, could "info_exist_lock" be reused for such purposes?
I think you can use the mlock for this purpose. Usually you'd have a flag in
your driver struct which you'd set to true in suspend and to false in
resume. And in the read_raw callback you'd check that flag before accessing
the hardware. If it turns out that this is a common pattern it probably
makes sense to add infrastructure for this to the IIO core. Something along
the lines of:
static int drv_suspend(...)
{
...
iio_device_set_suspended(iio_dev, true);
...
}
static int drv_suspend(...)
{
...
iio_device_set_suspended(iio_dev, false);
...
}
and then have the IIO core check that flag before calling the read_raw callback.
- Lars
>
> Regards,
> -grygorii
>
>
> On 07/12/2013 10:56 PM, Lars-Peter Clausen wrote:
>>
>> A couple of comments inline.
>>
>> On 07/12/2013 09:18 AM, Oleksandr Kozaruk wrote:
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index ab0767e6..87d699e 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -157,4 +157,12 @@ config VIPERBOARD_ADC
>>> Say yes here to access the ADC part of the Nano River
>>> Technologies Viperboard.
>>>
>>> +config TWL6030_GPADC
>>> +tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
>>> +depends on TWL4030_CORE
>>> +default n
>>> +help
>>> + Say yes here if you want support for the TWL6030 General Purpose
>>> + A/D Convertor.
>>> +
>>
>> Keep it in alphabetical order
>>
>>> endmenu
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 0a825be..8b05633 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
>>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>> obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>> obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
>>> +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>>
>> Same here.
>>
>>> diff --git a/drivers/iio/adc/twl6030-gpadc.c
>>> b/drivers/iio/adc/twl6030-gpadc.c
>>> new file mode 100644
>>> index 000..6ceb789
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/twl6030-gpadc.c
>>> @@ -0,0 +1,1019 @@
>> [...]
>>> +static u8 twl6032_channel_to_reg(int channel)
>>> +{
>>> +return TWL6032_GPADC_GPCH0_LSB;
>>
>> There is more than one channel, isn't there?
>>
>> [...]
>> > +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
>> > + const struct iio_chan_spec *chan,
>> > + int *val, int *val2, long mask)
>> > +{
>> > +struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
>> > +int ret = -EINVAL;
>> > +
>> > +mutex_lock(&gpadc->lock);
>> > +
>> > +ret = gpadc->pdata->start_conversion(chan->channel);
>> > +if (ret) {
>> > +dev_err(gpadc->dev, "failed to start conversion\n");
>> > +goto err;
>> > +}
>> > +/* wait for conversion to complete */
>> > +wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
>> > +msecs_to_jiffies(5000));
>>
>> wait_for_completion_interruptible_timeout() can return either a negative
>> error code if it was interrupted, 0 if it timed out, or a positive value
>> if it was successfully completed. You need to handle all three cases.
>> Have a look at other existing drivers to see how to do this properly.
>>
>> > +
>> > +switch (mask) {
>> > +case IIO_CHAN_INFO_RAW:
>> > +ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
>> > +ret = ret ? -EIO : IIO_VAL_INT;
>> > +break;
>> > +
>> > +case IIO_CHAN_INFO_PROCESSED:
>> > +ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
>> > +ret = ret ? -EIO : IIO_VAL_INT;
>> > +break;
>> > +
>> > +default:
>> > +break;
>> > +}
>> > +err:
>> > +mutex_unlock(&gpadc->lock);
>> > +
>> > +return ret;
>> > +}
>>
>>> +}
>>> +
>> [...]
>>> +static int twl6030_gpadc_probe(struct platform_device *pdev)
>>> +{
>>> +struct device *dev = &pdev->dev;
>>> +struct twl6030_gpadc_data *gpadc;
>>> +const struct twl6030_gpadc_platform_data *pdata;
>>> +const struct of_device_id *match;
>>> +struct iio_dev *indio_dev;
>>> +int irq;
>>> +int ret = 0;
>>> +
>>> +match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
>>> +pdata = match ? match->data : dev->platform_data;
>>> +
>>> +if (!pdata)
>>> +
Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hi All,
I have a question regarding this patch and IIO in general
- Does IIO provide sync mechanism with system wide suspend/resume or
this should be handled by each driver itself?
What if during system suspend iio_read_channel_raw() (or any other
consumer API) will be called after gpadc driver have been suspended
already? (I did some investigation and seems it's possible - Am I right?)
If no, could "info_exist_lock" be reused for such purposes?
Regards,
-grygorii
On 07/12/2013 10:56 PM, Lars-Peter Clausen wrote:
A couple of comments inline.
On 07/12/2013 09:18 AM, Oleksandr Kozaruk wrote:
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..87d699e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,4 +157,12 @@ config VIPERBOARD_ADC
Say yes here to access the ADC part of the Nano River
Technologies Viperboard.
+config TWL6030_GPADC
+tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
+depends on TWL4030_CORE
+default n
+help
+ Say yes here if you want support for the TWL6030 General Purpose
+ A/D Convertor.
+
Keep it in alphabetical order
endmenu
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..8b05633 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
Same here.
diff --git a/drivers/iio/adc/twl6030-gpadc.c
b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 000..6ceb789
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1019 @@
[...]
+static u8 twl6032_channel_to_reg(int channel)
+{
+return TWL6032_GPADC_GPCH0_LSB;
There is more than one channel, isn't there?
[...]
> +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> +struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
> +int ret = -EINVAL;
> +
> +mutex_lock(&gpadc->lock);
> +
> +ret = gpadc->pdata->start_conversion(chan->channel);
> +if (ret) {
> +dev_err(gpadc->dev, "failed to start conversion\n");
> +goto err;
> +}
> +/* wait for conversion to complete */
> +wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
> +msecs_to_jiffies(5000));
wait_for_completion_interruptible_timeout() can return either a negative
error code if it was interrupted, 0 if it timed out, or a positive value
if it was successfully completed. You need to handle all three cases.
Have a look at other existing drivers to see how to do this properly.
> +
> +switch (mask) {
> +case IIO_CHAN_INFO_RAW:
> +ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
> +ret = ret ? -EIO : IIO_VAL_INT;
> +break;
> +
> +case IIO_CHAN_INFO_PROCESSED:
> +ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
> +ret = ret ? -EIO : IIO_VAL_INT;
> +break;
> +
> +default:
> +break;
> +}
> +err:
> +mutex_unlock(&gpadc->lock);
> +
> +return ret;
> +}
+}
+
[...]
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+struct device *dev = &pdev->dev;
+struct twl6030_gpadc_data *gpadc;
+const struct twl6030_gpadc_platform_data *pdata;
+const struct of_device_id *match;
+struct iio_dev *indio_dev;
+int irq;
+int ret = 0;
+
+match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+pdata = match ? match->data : dev->platform_data;
+
+if (!pdata)
+return -EINVAL;
+
+indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
sizeof(*gpadc)
+if (!indio_dev) {
+dev_err(dev, "failed allocating iio device\n");
+ret = -ENOMEM;
+}
+
+gpadc = iio_priv(indio_dev);
+
+gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+sizeof(struct twl6030_chnl_calib) *
+pdata->nchannels, GFP_KERNEL);
+if (!gpadc->twl6030_cal_tbl)
+goto err;
+
+gpadc->dev = dev;
+gpadc->pdata = pdata;
+
+platform_set_drvdata(pdev, indio_dev);
+mutex_init(&gpadc->lock);
+init_completion(&gpadc->irq_complete);
+
+ret = pdata->calibrate(gpadc);
+if (ret < 0) {
+dev_err(&pdev->dev, "failed to read calibration registers\n");
+goto err;
+}
+
+irq = platform_get_irq(pdev, 0);
+if (irq < 0) {
+dev_err(&pdev->dev, "failed to get irq\n");
+goto err;
+}
+
+ret = devm_request_threaded_irq(dev, irq, NULL,
+twl6030_gpadc_irq_handler,
+IRQF_ONESHOT, "twl6030_gpadc", gpadc);
You access memory in the inter
Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote: [...] > >>> + ret = devm_request_threaded_irq(dev, irq, NULL, >>> + twl6030_gpadc_irq_handler, >>> + IRQF_ONESHOT, "twl6030_gpadc", gpadc); >> >> You access memory in the interrupt handler which is freed before the >> interrupt >> handler is freed. > Thanks for pointing this. devm_* will free memory for irq after the driver > is removed and memory for the device is freed. I took me awhile to understand > this. Is there going to be something like devm_iio_device_alloc? whould it be > helpfull? > Yes, I think it certainly makes sense to add a devm_iio_device_alloc(), care to send a patch? -- 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 v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Lars-Peter,
Thank you for the review.
>> diff --git a/drivers/iio/adc/twl6030-gpadc.c
>> b/drivers/iio/adc/twl6030-gpadc.c
>> new file mode 100644
>> index 000..6ceb789
>> --- /dev/null
>> +++ b/drivers/iio/adc/twl6030-gpadc.c
>> @@ -0,0 +1,1019 @@
>[...]
>> +static u8 twl6032_channel_to_reg(int channel)
>> +{
>> + return TWL6032_GPADC_GPCH0_LSB;
>
>There is more than one channel, isn't there?
Yes. But for twl6032 channel of interest is chosen first. When the conversion
is ready tre result is available in GPCH0_LSB/GPCH1_MSB for any cosen
channel. For twl6030 there are as many result register pairs as many of
channels.
>> + ret = devm_request_threaded_irq(dev, irq, NULL,
>> + twl6030_gpadc_irq_handler,
>> + IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>
>You access memory in the interrupt handler which is freed before the interrupt
>handler is freed.
Thanks for pointing this. devm_* will free memory for irq after the driver
is removed and memory for the device is freed. I took me awhile to understand
this. Is there going to be something like devm_iio_device_alloc? whould it be
helpfull?--
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: Boot hang regression 3.10.0-rc4 -> 3.10.0
On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>> Hi,
>>>
>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi [130710 09:18]:
>
> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>
>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>> Author: Felipe Balbi
>> Date: Wed Jul 10 18:50:16 2013 +0300
>>
>> arm: omap2plus: unidle devices which are about to probe
>>
>> in order to make HWMOD and pm_runtime agree on the
>> initial state of the device, we will unidle the device
>> and call pm_runtime_set_active() to tell pm_runtime
>> that the device is really active.
>>> Don't think that it's good idea (
>>> I've checked some driver's and think this patch will enable some devices
>>> unpredictably:
>>> - hwspinlock
>>> - mailbox
>>> - iommu
>>> - ipu
>>> All above devices need to be enabled on demand only (no
>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>> specific enabling sequence - like ipu).
>>>
>>> May be Summan can say more on that.
>>
>> Indeed, this is a problem for any of the slave processor devices.
>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>> a specific sequence of bringing up a processor. The current
>> hwmod/omap_device code is such that these devices will be left in reset
>> and the driver code use the omap_device_(de)assert_hardreset API
>> together with omap_device_enable code to bring up the devices. The
>> remoteproc driver also needs to assert the resets (there are other
>> problems associated with using omap_device_idle for remoteproc and
>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>> and mailbox may get away since they are in CORE domain, but definitely
>> an issue for iommu and remoteproc. I would think that this would also
>> affect other compute devices like IVAHD, ISS, SGX.
>
> Today, for these IPs I guess hwmod waits for the resets to be de-asserted,
> right?
>
> /*
> * If an IP block contains HW reset lines and all of them are
> * asserted, we let integration code associated with that
> * block handle the enable. We've received very little
> * information on what those driver authors need, and until
> * detailed information is provided and the driver code is
> * posted to the public lists, this is probably the best we
> * can do.
> */
> if (_are_all_hardreset_lines_asserted(oh))
> return 0;
>
> What if this information is send back to omap_device() through a return value
> so omap_device() knows about this too, so it avoids marking the omap device as
> enabled? Wouldn't that fix the issue?
I meant something like this..
>From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak
Date: Mon, 15 Jul 2013 15:23:07 +0530
Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
enable/idle/shutdown the hwmods
For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
enable/idle/shutdown operations as long as all the hard reset lines are
kept asserted. However it does not return an error back to the caller (in some
cases the omap_device layer) to communicate back the failure to operate on the
hwmod.
Fix this by making _enable()/_idle()/_shutdown() all return an error in such
cases, and also fix the omap_device layer to look at the return values coming
from hwmod operations before doing a omap_device level state transition.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_device.c | 20 ++--
arch/arm/mach-omap2/omap_hwmod.c |6 +++---
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..e89244b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -210,13 +210,12 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
*/
static int _omap_device_enable_hwmods(struct omap_device *od)
{
- int i;
+ int i, ret = 0;
for (i = 0; i < od->hwmods_cnt; i++)
- omap_hwmod_enable(od->hwmods[i]);
+ ret |= omap_hwmod_enable(od->hwmods[i]);
- /* XXX pass along return value here? */
- return 0;
+ return ret;
}
/**
@@ -227,13 +226,12 @@ static int _omap_device_enable_hwmods(struct omap_device
*od)
*/
static int _omap_device_idle_hwmods(struct
Re: [PATCH] arm: omap5: dts: add palmas-usb node
On Fri, Jul 12, 2013 at 07:14:41PM +0300, Felipe Balbi wrote: > Without this node, there will be no palmas > driver to notify dwc3 that a cable has > been connected and, without that, dwc3 > will never initialize. > > Signed-off-by: Felipe Balbi > --- > > after this, all we need is wait EXTCON merge > which contains the final changes necessary > to get USB3 working out of the box. > > I'd suggest waiting on this patch until EXTCON > reaches mainline, just to make sure we don't > end up with DTS data for devices which don't > exist. this is not entirely correct. v3.11-rc1 has almost everything we need, already have a newer version of this patch but dwc3 has decided not to behave. don't apply this version -- balbi signature.asc Description: Digital signature
Re: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
On Tuesday 09 July 2013 05:06 PM, Tony Lindgren wrote:
+/* dma_system */
> >> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
> >> + { .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
> >> + { .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
> >> + { .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
> >> + { .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
> >> + { .irq = -1 }
> >> +};
>>> > >
>>> > > I think these should no longer be needed?
>> >
>> > These are needed only for dma because mach-omap2/dma.c still creates
>> > devices from hmwod and which are used by plat/dma.c.
>> > These irqs for sdma exist even in the cleaned up omap4 and omap5 hmwod
>> > files.
>> > I'll try and get rid of that dependency of plat/dma on mach/dma to create
>> > devices.
> OK great.
Looks like this wouldn't be possible because drivers/dma/omap-dma.c is the one
which is
probing the sdma device created using device tree. So we can't have
plat-omap/dma.c probe the
same device.
>
--
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] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/15/2013 10:16 AM, Roger Quadros wrote: >>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC >>> ethernet chip >>> as I don't have an external USB-ethernet adapter. >> >> Too bad. This difference in boards makes the tests a bit less >> meaningful. Is there really no USB-ethernet adapter somewhere in your >> department (perhaps a non-SMSC95xx might serve as well?)? I might >> send/order you one if necessary. ;) > > Thanks for the offer :). I'll just get one for myself by today/tomorrow. > The one available here uses this driver "drivers/net/usb/asix.c" Great. >> >>> The above commit doesn't work well for beagle-xm, >> >> Why is this? What does happen? Does U-Boot not boot up to the prompt? >> Please send me a log. > > The last time it had failed I remember seeing a lot of IO pad configuration > errors. > But I'm no longer able to reproduce that problem. Maybe it was just a messed > up > build. In case I observe it again I'll let you know. It might be related to a problem with the gd (global-data) pointer being overwritten in den SPL. This is still not finally resolved the upcoming release: http://patchwork.ozlabs.org/patch/251293/ >> >>> so my u-boot is on tag v2013.04 >>> and you don't need that additional patch. >>> >>> Can you please retest on it? Thanks. >> >> Done, please see below. >> >>> You will need to set "usbethaddr" before starting USB else SMSC will not >>> work. >>> e.g. >>> setenv usbethaddr A6:66:4D:B0:69:04 >> >> I don't have a beagle-xm, only my beable. And my U-Boot network setup is >> already working, thanks. > > Right. you won't need that for beagle. It was only for beagle-xm or panda > with on board > usb-ethernet. I'm using the (external) USB-ethernet adapter on the beagle in U-Boot as well. To tftp the kernel/dtb. Thanks, Stefan -- 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 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
On 07/14/2013 04:22 PM, Kevin Hilman wrote:
> On 07/10/2013 05:23 PM, Roger Quadros wrote:
>> In order to support wake up from suspend use the pinctrl
>> framework to put the USB host pins in IDLE state during suspend.
>>
>> CC: Samuel Ortiz
>> Signed-off-by: Roger Quadros
>
> [...]
>
>> @@ -608,6 +618,14 @@ static int usbhs_omap_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> }
>>
>> +if (!dev->pins || !dev->pins->idle_state) {
>> +/* If IDLE pins are not available, we can't remote wakeup,
>> + * so prevent idling in that case.
>> + */
>
> nit: multi-line comment style
>
> Also, if there are no pins, aren't the pinctrl ops nops anyways? IOW,
> not sure the need
> for this is clear, and it's not mentioned in the changelog.
The pinctrl ops are nops but the runtime suspend isn't. So in this case,
we'll never be able to wake up the USB controller.
I'll update the changelog to reflect this.
cheers,
-roger
--
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] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/12/2013 01:52 PM, Stefan Roese wrote: > Roger, > > On 07/12/2013 11:15 AM, Roger Quadros wrote: Good idea. I'm currently using a "dirty" local version. I'll try to switch to an officially available version tomorrow. And send you the version/git id. >>> >>> I updated my U-Boot to the following version: Based on mainline git >>> commit ID 225fd8c. Only this patch added: >>> >>> http://patchwork.ozlabs.org/patch/256702/ >>> >>> This is needed for USB to work in U-Boot. Otherwise my external USB >>> SMSC95xx will not be detected in U-Boot. >> >> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC >> ethernet chip >> as I don't have an external USB-ethernet adapter. > > Too bad. This difference in boards makes the tests a bit less > meaningful. Is there really no USB-ethernet adapter somewhere in your > department (perhaps a non-SMSC95xx might serve as well?)? I might > send/order you one if necessary. ;) Thanks for the offer :). I'll just get one for myself by today/tomorrow. The one available here uses this driver "drivers/net/usb/asix.c" > >> The above commit doesn't work well for beagle-xm, > > Why is this? What does happen? Does U-Boot not boot up to the prompt? > Please send me a log. The last time it had failed I remember seeing a lot of IO pad configuration errors. But I'm no longer able to reproduce that problem. Maybe it was just a messed up build. In case I observe it again I'll let you know. > >> so my u-boot is on tag v2013.04 >> and you don't need that additional patch. >> >> Can you please retest on it? Thanks. > > Done, please see below. > >> You will need to set "usbethaddr" before starting USB else SMSC will not >> work. >> e.g. >> setenv usbethaddr A6:66:4D:B0:69:04 > > I don't have a beagle-xm, only my beable. And my U-Boot network setup is > already working, thanks. Right. you won't need that for beagle. It was only for beagle-xm or panda with on board usb-ethernet. > >> Also could you please increase the Linux console message verbosity to debug >> (8), so that >> all kernel messages are visible in the log? If it spits out something more >> than what you >> sent last time then do send it to me. > > I added "ignore_loglevel" to the cmdline. But I cannot see anything > interesting that has not been there before with "debug" as well. OK. cheers, -roger -- 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] ARM: multi_v7: Enabled omap4430 sdp nfsroot
Author: Tony Lindgren Date: Mon Jul 15 00:39:41 2013 -0700 ARM: multi_v7: Enabled omap4430 sdp nfsroot By adding support for OCP2SCP, SPI and KS8851 I can also boot test multi_v7_defconfig easily. Note that if using an older u-boot, CONFIG_ARM_ATAG_DTB_COMPAT=y may also be needed for the appended DTB based booting. Signed-off-by: Tony Lindgren --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -53,6 +53,7 @@ CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_OMAP_OCP2SCP=y CONFIG_BLK_DEV_SD=y CONFIG_ATA=y CONFIG_SATA_AHCI_PLATFORM=y @@ -61,6 +62,7 @@ CONFIG_SATA_MV=y CONFIG_NETDEVICES=y CONFIG_SUN4I_EMAC=y CONFIG_NET_CALXEDA_XGMAC=y +CONFIG_KS8851=y CONFIG_SMSC911X=y CONFIG_STMMAC_ETH=y CONFIG_MDIO_SUN4I=y @@ -89,6 +91,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=y CONFIG_I2C_SIRF=y CONFIG_I2C_TEGRA=y CONFIG_SPI=y +CONFIG_SPI_OMAP24XX=y CONFIG_SPI_PL022=y CONFIG_SPI_SIRF=y CONFIG_SPI_TEGRA114=y -- 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
