Re: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Yuvaraj, On Fri, Jun 27, 2014 at 3:59 AM, Yuvaraj Kumar wrote: >>> mmc_regulator_set_ocr() is failing as its a fixed-regulator. >> >> Can you explain more about what's failing? It sure looks like mmc >> core is supposed to handle this given comments below >> >> /* >> * If we're using a fixed/static regulator, don't call >> * regulator_set_voltage; it would fail. >> */ > tps65090 driver does not register through fixed regulator framework.It > uses normal regulator framework and supports only > enable/disable/is_enabled callbacks.Also it lacks certain callbacks > for list_voltage, get_voltage ,set_voltage etc. > [2.306476] dwmmc_exynos 1222.mmc: Failed getting OCR mask: -22 > [2.393403] dwmmc_exynos 1222.mmc: could not set regulator OCR (-22) > For the above reason,regulator framework treats fet4 as unused > regulator and disables the vmmc regulator. Ah. Perhaps tps65090 needs to be fixed then... I'm not sure any other drivers cared before so maybe that's why it was never caught? -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On 6/25/2014 2:18 AM, Will Deacon wrote:
> On Tue, Jun 24, 2014 at 10:35:54PM +0100, Olav Haugan wrote:
>> On 6/24/2014 11:11 AM, Will Deacon wrote:
>>> On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
> On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
>> We have multiple-master SMMUs and each master emits a variable number of
>> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
>> for this) to the StreamIDs due to limited number of StreamID 2 Context
>> Bank entries in the SMMU. If my understanding is correct we would
>> represent this in the DT like this:
>>
>> iommu {
>> #address-cells = <2>;
>> #size-cells = <0>;
>> };
>>
>> master@a {
>> ...
>> iommus = <&iommu StreamID0 MASK0>,
>> <&iommu StreamID1 MASK1>,
>> <&iommu StreamID2 MASK2>;
>> };
>
> Stupid question, but why not simply describe the masked IDs? What use does
> the `raw' ID have to Linux?
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?
We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.
>>>
>>> Hmm, so you're talking about stream matching, right? That doesn't belong in
>>> the device-tree. I appreciate that the current driver does a terrible job at
>>> allocating the SMRs (it's bloody difficult!), but we should try to improve
>>> the dynamic behaviour instead of moving configuration of the SMMU out into
>>> device-tree, where it's inflexible at best.
>>
>> I am talking about SMMU_SMRn[MASK] register bits. This is not something
>> that can be dynamically detected at run-time. It is configuration at the
>> same level as the actual StreamIDs.
>
> Why can't it be dynamically detected? Whilst the StreamIDs are fixed in
> hardware (from the SMMU architecture perspective), the SMRs are completely
> programmable. Why doesn't something like Andreas's proposal work for you?
> The idea there was to find the constant bits among the StreamIDs for a
> master and create the mask accordingly.
>
Lets say I have an IOMMU with 2 masters and 2 SMRn slots with the
following stream IDs coming from the masters:
Master 1: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
Master 2: 0x30
To make this work I would program SMR[0] with StreamID 0x20 and mask 0xF
to ignore lower 4 bits. SMR[1] would just be StreamID 0x30 with mask 0x0.
However, I could also have an IOMMU with 2 masters and 9 SMRn slots with
the following stream IDs:
Master 1: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
Master 2: 0x29
Here I would program all SMRn and leave the mask to be 0 for all SMRn's.
So how do I detect when to apply a mask or not?
I am not familiar with Andreas's proposal. Do you have a link?
Thanks,
Olav Haugan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
Stephen, On Fri, Jun 27, 2014 at 12:56 PM, Stephen Warren wrote: > On 06/27/2014 12:30 PM, Doug Anderson wrote: >> Stephen, >> >> On Fri, Jun 27, 2014 at 11:20 AM, Stephen Warren >> wrote: >>> On 06/27/2014 10:45 AM, Doug Anderson wrote: Stephen, On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren wrote: > Surely there's a driver (or could be a driver) for the TPM chip, and > that driver should have a reset-mask-gpios property, so the driver can > call gpio_get() and gpio_set_output() on the GPIO? > > Faking this out via a not-really-a-regulator or pinctrl hogs seems like > an abuse of those features to me. > ... >>> As an aside, why do we even care about this? The kernel clearly can >>> unlock the TPM simply by failing to set the GPIO up correctly, so at >>> best this is security through obscurity. If someone actively wanted to >>> do something bad to the TPM, they'd simply comment out this piece of >>> code in the kernel. At least that's true with usptream kernels which >>> aren't validated at all during boot. For a downstream signed kernel, >>> perhaps this patch makes sense (although I haven't thought about all the >>> security angles), but then it'd make sense to keep this patch downstream. >> >> Check out the bullet point about the firmware checking for kernel >> cheats. At resume time the chip actually re-loads read only firmware >> out of SPI flash (no choice about this). This read only firmware can >> check the state of the mask pin (which is preserved across sleep wake) >> to see if the kernel cheated. > > Ah, that covers the security issues then. > > I'd argue that the RO firmware should be setting up GPIOs like this > myself (and the pinmux, from a nice big table), and the kernel simply > not touch it all since it has no direct use for the pin. But I suppose > if the firmware is already baked and read only, that's not possible. Yes. Earlier in this thread I said I had no idea why I didn't have firmware set this up. I couldn't come up with a good reason... :( -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
On 06/27/2014 12:30 PM, Doug Anderson wrote: > Stephen, > > On Fri, Jun 27, 2014 at 11:20 AM, Stephen Warren > wrote: >> On 06/27/2014 10:45 AM, Doug Anderson wrote: >>> Stephen, >>> >>> On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren >>> wrote: Surely there's a driver (or could be a driver) for the TPM chip, and that driver should have a reset-mask-gpios property, so the driver can call gpio_get() and gpio_set_output() on the GPIO? Faking this out via a not-really-a-regulator or pinctrl hogs seems like an abuse of those features to me. ... >> As an aside, why do we even care about this? The kernel clearly can >> unlock the TPM simply by failing to set the GPIO up correctly, so at >> best this is security through obscurity. If someone actively wanted to >> do something bad to the TPM, they'd simply comment out this piece of >> code in the kernel. At least that's true with usptream kernels which >> aren't validated at all during boot. For a downstream signed kernel, >> perhaps this patch makes sense (although I haven't thought about all the >> security angles), but then it'd make sense to keep this patch downstream. > > Check out the bullet point about the firmware checking for kernel > cheats. At resume time the chip actually re-loads read only firmware > out of SPI flash (no choice about this). This read only firmware can > check the state of the mask pin (which is preserved across sleep wake) > to see if the kernel cheated. Ah, that covers the security issues then. I'd argue that the RO firmware should be setting up GPIOs like this myself (and the pinmux, from a nice big table), and the kernel simply not touch it all since it has no direct use for the pin. But I suppose if the firmware is already baked and read only, that's not possible. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
On Fri, Jun 27, 2014 at 5:31 AM, Wolfram Sang wrote: > On Wed, Jun 18, 2014 at 11:14:04AM -0700, Doug Anderson wrote: >> From: Bill Richardson >> >> Remove the three wrapper functions that talk to the EC without passing all >> the desired arguments and just use the underlying communication function >> that passes everything in a struct intead. >> >> This is internal code refactoring only. Nothing should change. >> >> Signed-off-by: Bill Richardson >> Signed-off-by: Doug Anderson >> Acked-by: Lee Jones >> Reviewed-by: Simon Glass > > For the I2C part: > > Acked-by: Wolfram Sang > I'm good with input bits as well. Acked-by: Dmitry Torokhov Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
Stephen, On Fri, Jun 27, 2014 at 11:20 AM, Stephen Warren wrote: > On 06/27/2014 10:45 AM, Doug Anderson wrote: >> Stephen, >> >> On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren >> wrote: >>> Surely there's a driver (or could be a driver) for the TPM chip, and >>> that driver should have a reset-mask-gpios property, so the driver can >>> call gpio_get() and gpio_set_output() on the GPIO? >>> >>> Faking this out via a not-really-a-regulator or pinctrl hogs seems like >>> an abuse of those features to me. >> >> This totally doesn't belong in the TPM chip driver. This is an >> unabashed HACK at the board level. Without a hog we need a board >> driver for this. >> >> To be more specific: >> >> * The TPM needs to be reset when the full system gets reset. This >> unlocks the TPM and allows certain types of updates by the firmware. >> The firmware then locks the TPM before jumping to the kernel. >> >> * The TPM is hooked up to the "reset out" line of the CPU so that when >> the system does a warm reset it will reset the TPM. >> >> * Unfortunately the CPU asserts the "reset out" line when it's >> sleeping (because, of course, sleep is a reset). This would allow the >> kernel to unlock the TPM which it's not supposed to be able to do. > > To me, this does sound precisely like something that should be in the > TPM driver. I guess an overall board driver would be reasonable too, > since the issue probably doesn't to all boards with the TPM. Right. In fact I'd be willing to bet that there are zero other boards (other than the ChromeOS boards with similar heritage) with this TPM that do this. It does seem unfair to burden an Infineon driver with a board hack when it's something they didn't have anything to do with. ...but if that's the way it has to be then that's the way it has to be... If consensus is a board driver that's fine too. It's really all about coming up with some solution that will make folks happy. > This kind of thing is *exactly* the kind of thing that's been discussed > in the past re: doing it in pinmux hogs, or GPIO initialization tables > that aren't specific to a driver, and has been rejected. I guess if > people want to change the decisions that's fine, but doing so will open > up the door to all the previously rejected similar use-cases. I'm not > sure how much I care either way, but we really should be consistent > instead of flip-flopping on this kind of issue. > > As an aside, why do we even care about this? The kernel clearly can > unlock the TPM simply by failing to set the GPIO up correctly, so at > best this is security through obscurity. If someone actively wanted to > do something bad to the TPM, they'd simply comment out this piece of > code in the kernel. At least that's true with usptream kernels which > aren't validated at all during boot. For a downstream signed kernel, > perhaps this patch makes sense (although I haven't thought about all the > security angles), but then it'd make sense to keep this patch downstream. Check out the bullet point about the firmware checking for kernel cheats. At resume time the chip actually re-loads read only firmware out of SPI flash (no choice about this). This read only firmware can check the state of the mask pin (which is preserved across sleep wake) to see if the kernel cheated. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
On 06/27/2014 10:45 AM, Doug Anderson wrote: > Stephen, > > On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren wrote: >> Surely there's a driver (or could be a driver) for the TPM chip, and >> that driver should have a reset-mask-gpios property, so the driver can >> call gpio_get() and gpio_set_output() on the GPIO? >> >> Faking this out via a not-really-a-regulator or pinctrl hogs seems like >> an abuse of those features to me. > > This totally doesn't belong in the TPM chip driver. This is an > unabashed HACK at the board level. Without a hog we need a board > driver for this. > > To be more specific: > > * The TPM needs to be reset when the full system gets reset. This > unlocks the TPM and allows certain types of updates by the firmware. > The firmware then locks the TPM before jumping to the kernel. > > * The TPM is hooked up to the "reset out" line of the CPU so that when > the system does a warm reset it will reset the TPM. > > * Unfortunately the CPU asserts the "reset out" line when it's > sleeping (because, of course, sleep is a reset). This would allow the > kernel to unlock the TPM which it's not supposed to be able to do. To me, this does sound precisely like something that should be in the TPM driver. I guess an overall board driver would be reasonable too, since the issue probably doesn't to all boards with the TPM. This kind of thing is *exactly* the kind of thing that's been discussed in the past re: doing it in pinmux hogs, or GPIO initialization tables that aren't specific to a driver, and has been rejected. I guess if people want to change the decisions that's fine, but doing so will open up the door to all the previously rejected similar use-cases. I'm not sure how much I care either way, but we really should be consistent instead of flip-flopping on this kind of issue. As an aside, why do we even care about this? The kernel clearly can unlock the TPM simply by failing to set the GPIO up correctly, so at best this is security through obscurity. If someone actively wanted to do something bad to the TPM, they'd simply comment out this piece of code in the kernel. At least that's true with usptream kernels which aren't validated at all during boot. For a downstream signed kernel, perhaps this patch makes sense (although I haven't thought about all the security angles), but then it'd make sense to keep this patch downstream. > * To solve the problem, it's up to the kernel to "mask" out the reset > line before going to sleep. Then it's up to the read only firmware to > validate that the kernel properly masked the reset before resuming > from sleep. If the firmware finds that the kernel cheated and didn't > mask the reset then it will not resume to the kernel and will instead > restart the system. > > > The above is not beautiful in the least sense. Getting suspend/resume > working happened very late in the exynos5250-snow project and the > above workaround was the best that we could come up with without > slipping schedules. It also had the side effect of being less > expensive than other solutions. Given that the solution was "proven > out" for exynos5250-snow, it was kept in place for similar products. > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
On Fri, Jun 27, 2014 at 9:32 AM, Doug Anderson wrote: > Felipe, > > On Fri, Jun 27, 2014 at 8:59 AM, Felipe Balbi wrote: >>> I'll admit to not having been involved with the previous discussions, >>> but this seems strange to me. Are we throwing in the towel and >>> deciding that it's too hard to get the Kconfigs right and that we'll >>> just rely on individual users to figure out the right answer for >>> themselves? >> >> no. select prevents a driver from be built as a dynamically linked >> module and distro-kernels might want to enable everything as modules. > > Ah, that's what the problem was! I wasn't aware of this issue with > SELECT. Sorry for the noob-ness. Select is also fragile, for example if a main subsystem isn't enabled, the specific option will still be enabled (or there'll be a warning/error about it). Overall it tends to cause headaches so many maintainers are starting to push back against it. > Really we want the PHY to be "=y" if the USB driver is "=y" or "=m" if > the USB driver is "=m", I think. You could argue that one might want > to build the main USB driver into the kernel but have the phy drivers > as modules, so you could possibly also try to support that... > > If there's not a good way to specify that, I guess we'll just have to > use "default" and rely on the user not to purposely choose the wrong > thing. Like the following (untested): > > config PHY_SAMSUNG_USB2 > depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS > default y if ARCH_EXYNOS=y && (USB_OHCI_EXYNOS=y || USB_EHCI_EXYNOS=y) > default m if ARCH_EXYNOS=m && (USB_OHCI_EXYNOS=m || USB_EHCI_EXYNOS=m) > ... > > I see some syntax like that elsewhere in Kconfig so I assume it's > reasonable... I think you can take out the test for ARCH_EXYNOS here (first of all, it can never be modular). I'm not sure it makes sense to work so hard to set the default right either, as long as the dependencies are correct. I.e. it'll still mess up randconfig if the combination doesn't build, and distros can still downgrade to 'm' if they want to. That'll just leave: config PHY_SAMSUNG_USB2 tristate "foo" depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS default y (no need to add an if since it's taken care of by the depends) > With the above the user could purposely enable the OHCI or EHCI driver > and disable the PHY driver which is not really sensible. ...but it > wouldn't cause a compile failure or crash--USB just won't work. Just make the sub-drivers silent options with defaults. I.e: config PHY_EXYNOS5250_USB2 bool SOC_EXYNOS5250 depends on PHY_SAMSUNG_USB2 and so on. Note that it doesn't actually scale to make it depend on a specific SoC though, so it should probably just be cut down the line of EXYNOS4/5 and err on the side of including a bit too much code instead. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
Stephen, On Fri, Jun 27, 2014 at 9:10 AM, Stephen Warren wrote: > Surely there's a driver (or could be a driver) for the TPM chip, and > that driver should have a reset-mask-gpios property, so the driver can > call gpio_get() and gpio_set_output() on the GPIO? > > Faking this out via a not-really-a-regulator or pinctrl hogs seems like > an abuse of those features to me. This totally doesn't belong in the TPM chip driver. This is an unabashed HACK at the board level. Without a hog we need a board driver for this. To be more specific: * The TPM needs to be reset when the full system gets reset. This unlocks the TPM and allows certain types of updates by the firmware. The firmware then locks the TPM before jumping to the kernel. * The TPM is hooked up to the "reset out" line of the CPU so that when the system does a warm reset it will reset the TPM. * Unfortunately the CPU asserts the "reset out" line when it's sleeping (because, of course, sleep is a reset). This would allow the kernel to unlock the TPM which it's not supposed to be able to do. * To solve the problem, it's up to the kernel to "mask" out the reset line before going to sleep. Then it's up to the read only firmware to validate that the kernel properly masked the reset before resuming from sleep. If the firmware finds that the kernel cheated and didn't mask the reset then it will not resume to the kernel and will instead restart the system. The above is not beautiful in the least sense. Getting suspend/resume working happened very late in the exynos5250-snow project and the above workaround was the best that we could come up with without slipping schedules. It also had the side effect of being less expensive than other solutions. Given that the solution was "proven out" for exynos5250-snow, it was kept in place for similar products. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Felipe, On Fri, Jun 27, 2014 at 8:59 AM, Felipe Balbi wrote: >> I'll admit to not having been involved with the previous discussions, >> but this seems strange to me. Are we throwing in the towel and >> deciding that it's too hard to get the Kconfigs right and that we'll >> just rely on individual users to figure out the right answer for >> themselves? > > no. select prevents a driver from be built as a dynamically linked > module and distro-kernels might want to enable everything as modules. Ah, that's what the problem was! I wasn't aware of this issue with SELECT. Sorry for the noob-ness. Really we want the PHY to be "=y" if the USB driver is "=y" or "=m" if the USB driver is "=m", I think. You could argue that one might want to build the main USB driver into the kernel but have the phy drivers as modules, so you could possibly also try to support that... If there's not a good way to specify that, I guess we'll just have to use "default" and rely on the user not to purposely choose the wrong thing. Like the following (untested): config PHY_SAMSUNG_USB2 depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS default y if ARCH_EXYNOS=y && (USB_OHCI_EXYNOS=y || USB_EHCI_EXYNOS=y) default m if ARCH_EXYNOS=m && (USB_OHCI_EXYNOS=m || USB_EHCI_EXYNOS=m) ... I see some syntax like that elsewhere in Kconfig so I assume it's reasonable... With the above the user could purposely enable the OHCI or EHCI driver and disable the PHY driver which is not really sensible. ...but it wouldn't cause a compile failure or crash--USB just won't work. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
On 06/27/2014 06:17 AM, Tomasz Figa wrote:
> Hi Doug,
>
> On 26.06.2014 17:25, Doug Anderson wrote:
>> Tomasz,
>>
>> On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote:
>>> Hi Vikas, Doug,
>>>
>>> On 26.06.2014 11:15, Vikas Sajjan wrote:
From: Doug Anderson
The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
being reset across sleep/wake. If we don't set it to anything then
the TPM will be reset. U-Boot will detect this as invalid
and will reset the system on resume time. This GPIO can always be low
and not hurt anything. It will get pulled back high again during a
normal warm reset when it will default back to an input.
To properly preserve the TPM state across suspend/resume and to make
the chrome U-Boot happy, properly set the GPIO to mask the
reset to the TPM.
Signed-off-by: Doug Anderson
Signed-off-by: Vikas Sajjan
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..8fd990a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -87,6 +87,18 @@
pinctrl-0 = <&usb301_vbus_en>;
enable-active-high;
};
+
+ /* We need GPX0_6 to be low at sleep time; just keep it low always */
+ mask_tpm_reset_regulator: mask-tpm-reset-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "mask-tpm-reset ";
+ gpio = <&gpx0 6 0>;
+ enable-active-low;
+ regulator-boot-on;
+ regulator-always-on;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mask_tpm_reset>;
+ };
>>>
>>> I don't think this pin is supposed to be a real regulator. If I'm right,
>>> you should just add a hog for it, if you don't have a proper driver to
>>> handle it.
>>
>> Yes, I agree that it shouldn't really be a regulator, but there's not
>> a whole lot of choice. The pin needs to actually be driven low, not
>> just pulled low. Without your proposed patch (pinctrl: samsung: Allow
>> pin value to be initialized using pinfunc) I don't think it's possible
>> to actually drive a pin low with a hog. I could be wrong, though.
Surely there's a driver (or could be a driver) for the TPM chip, and
that driver should have a reset-mask-gpios property, so the driver can
call gpio_get() and gpio_set_output() on the GPIO?
Faking this out via a not-really-a-regulator or pinctrl hogs seems like
an abuse of those features to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
On Fri, Jun 27, 2014 at 08:55:31AM -0700, Doug Anderson wrote: > Felipe, > > On Fri, Jun 27, 2014 at 8:46 AM, Felipe Balbi wrote: > > On Thu, Jun 26, 2014 at 11:09:37AM +0530, Sachin Kamat wrote: > >> EHCI and OHCI drivers on Exynos platforms do not work without their > >> corresponding SoC specific phy drivers. Hence it makes no sense to > >> keep these phy drivers as user selectable. Instead select them from > >> the respective USB configs to make things easier for the end user. > >> While at it enable 5250 phy for Exynos 5420 SoC too. > >> > >> Signed-off-by: Sachin Kamat > >> Cc: Kishon Vijay Abraham I > > > > no more selects, please. We've already had way too many issues because > > of misused selects. > > I'll admit to not having been involved with the previous discussions, > but this seems strange to me. Are we throwing in the towel and > deciding that it's too hard to get the Kconfigs right and that we'll > just rely on individual users to figure out the right answer for > themselves? no. select prevents a driver from be built as a dynamically linked module and distro-kernels might want to enable everything as modules. > Certainly the Exynos USB driver is not useful without the Exynos USB > Phy driver, so it seems awfully strange to allow the user to select > one without getting the other... ...and if including an extra USB Phy > driver will break something then it seems like we have bigger problems > (aren't we supposed to have one kernel that works across a wide > variety of boards?) yeah, but for the kernel to "work" it doesn't depend on the PHY driver, does it ? The USB parts of the SoC depend on the PHY, but even PHY drivers should be allowed to be built as modules. Find another way -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Felipe, On Fri, Jun 27, 2014 at 8:46 AM, Felipe Balbi wrote: > On Thu, Jun 26, 2014 at 11:09:37AM +0530, Sachin Kamat wrote: >> EHCI and OHCI drivers on Exynos platforms do not work without their >> corresponding SoC specific phy drivers. Hence it makes no sense to >> keep these phy drivers as user selectable. Instead select them from >> the respective USB configs to make things easier for the end user. >> While at it enable 5250 phy for Exynos 5420 SoC too. >> >> Signed-off-by: Sachin Kamat >> Cc: Kishon Vijay Abraham I > > no more selects, please. We've already had way too many issues because > of misused selects. I'll admit to not having been involved with the previous discussions, but this seems strange to me. Are we throwing in the towel and deciding that it's too hard to get the Kconfigs right and that we'll just rely on individual users to figure out the right answer for themselves? Certainly the Exynos USB driver is not useful without the Exynos USB Phy driver, so it seems awfully strange to allow the user to select one without getting the other... ...and if including an extra USB Phy driver will break something then it seems like we have bigger problems (aren't we supposed to have one kernel that works across a wide variety of boards?) -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
Doug,
On Fri, Jun 27, 2014 at 8:52 PM, Doug Anderson wrote:
> Tomasz,
>
> On Fri, Jun 27, 2014 at 8:14 AM, Tomasz Figa wrote:
>> On 27.06.2014 17:10, Doug Anderson wrote:
>>> Tomasz and Vikas,
>>>
>>> On Fri, Jun 27, 2014 at 5:17 AM, Tomasz Figa wrote:
Hi Doug,
On 26.06.2014 17:25, Doug Anderson wrote:
> Tomasz,
>
> On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote:
>> Hi Vikas, Doug,
>>
>> On 26.06.2014 11:15, Vikas Sajjan wrote:
>>> From: Doug Anderson
>>>
>>> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
>>> being reset across sleep/wake. If we don't set it to anything then
>>> the TPM will be reset. U-Boot will detect this as invalid
>>> and will reset the system on resume time. This GPIO can always be low
>>> and not hurt anything. It will get pulled back high again during a
>>> normal warm reset when it will default back to an input.
>>>
>>> To properly preserve the TPM state across suspend/resume and to make
>>> the chrome U-Boot happy, properly set the GPIO to mask the
>>> reset to the TPM.
>>>
>>> Signed-off-by: Doug Anderson
>>> Signed-off-by: Vikas Sajjan
>>> ---
>>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 20
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> index 7649982..8fd990a 100644
>>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> @@ -87,6 +87,18 @@
>>> pinctrl-0 = <&usb301_vbus_en>;
>>> enable-active-high;
>>> };
>>> +
>>> + /* We need GPX0_6 to be low at sleep time; just keep it low
>>> always */
>>> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "mask-tpm-reset ";
>>> + gpio = <&gpx0 6 0>;
>>> + enable-active-low;
>>> + regulator-boot-on;
>>> + regulator-always-on;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mask_tpm_reset>;
>>> + };
>>
>> I don't think this pin is supposed to be a real regulator. If I'm right,
>> you should just add a hog for it, if you don't have a proper driver to
>> handle it.
>
> Yes, I agree that it shouldn't really be a regulator, but there's not
> a whole lot of choice. The pin needs to actually be driven low, not
> just pulled low. Without your proposed patch (pinctrl: samsung: Allow
> pin value to be initialized using pinfunc) I don't think it's possible
> to actually drive a pin low with a hog. I could be wrong, though.
>
Uhm, I was convinced that this patch was already in. So I think your use
case is definitely a good reason to get back to this patch and use the
facility it provides to solve your problem.
>>>
>>> Thanks, that seems very reasonable to me, too.
>>>
>>> Are you going to pick up revitalizing this patch series or are you
>>> hoping Vikas will? IIRC I was in favor of your patch but it generated
>>> a whole bunch of discussion and never actually landed.
>>
>> I will respin it along with few other patches for pinctrl-samsung, but
>> obviously not before Monday.
>
> Sounds like a plan. Vikas: I'll assume you're going to redo this
> patch atop Tomasz's once he posts up his.
Sure, will respin atop Tomasz's patch series.
>
> -Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
On Thu, Jun 26, 2014 at 11:09:37AM +0530, Sachin Kamat wrote: > EHCI and OHCI drivers on Exynos platforms do not work without their > corresponding SoC specific phy drivers. Hence it makes no sense to > keep these phy drivers as user selectable. Instead select them from > the respective USB configs to make things easier for the end user. > While at it enable 5250 phy for Exynos 5420 SoC too. > > Signed-off-by: Sachin Kamat > Cc: Kishon Vijay Abraham I no more selects, please. We've already had way too many issues because of misused selects. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/4] drm: Constify struct drm_fb_helper_funcs
On Fri, Jun 27, 2014 at 05:19:23PM +0200, Thierry Reding wrote: > From: Thierry Reding > > There's no need for this to be modifiable. Make it const so that it can > be put into the .rodata section. > > Reviewed-by: Daniel Vetter > Signed-off-by: Thierry Reding Definitely a good thing. For Armada: Acked-by: Russell King -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
Tomasz,
On Fri, Jun 27, 2014 at 8:14 AM, Tomasz Figa wrote:
> On 27.06.2014 17:10, Doug Anderson wrote:
>> Tomasz and Vikas,
>>
>> On Fri, Jun 27, 2014 at 5:17 AM, Tomasz Figa wrote:
>>> Hi Doug,
>>>
>>> On 26.06.2014 17:25, Doug Anderson wrote:
Tomasz,
On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote:
> Hi Vikas, Doug,
>
> On 26.06.2014 11:15, Vikas Sajjan wrote:
>> From: Doug Anderson
>>
>> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
>> being reset across sleep/wake. If we don't set it to anything then
>> the TPM will be reset. U-Boot will detect this as invalid
>> and will reset the system on resume time. This GPIO can always be low
>> and not hurt anything. It will get pulled back high again during a
>> normal warm reset when it will default back to an input.
>>
>> To properly preserve the TPM state across suspend/resume and to make
>> the chrome U-Boot happy, properly set the GPIO to mask the
>> reset to the TPM.
>>
>> Signed-off-by: Doug Anderson
>> Signed-off-by: Vikas Sajjan
>> ---
>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> index 7649982..8fd990a 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -87,6 +87,18 @@
>> pinctrl-0 = <&usb301_vbus_en>;
>> enable-active-high;
>> };
>> +
>> + /* We need GPX0_6 to be low at sleep time; just keep it low always
>> */
>> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
>> + compatible = "regulator-fixed";
>> + regulator-name = "mask-tpm-reset ";
>> + gpio = <&gpx0 6 0>;
>> + enable-active-low;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mask_tpm_reset>;
>> + };
>
> I don't think this pin is supposed to be a real regulator. If I'm right,
> you should just add a hog for it, if you don't have a proper driver to
> handle it.
Yes, I agree that it shouldn't really be a regulator, but there's not
a whole lot of choice. The pin needs to actually be driven low, not
just pulled low. Without your proposed patch (pinctrl: samsung: Allow
pin value to be initialized using pinfunc) I don't think it's possible
to actually drive a pin low with a hog. I could be wrong, though.
>>>
>>> Uhm, I was convinced that this patch was already in. So I think your use
>>> case is definitely a good reason to get back to this patch and use the
>>> facility it provides to solve your problem.
>>
>> Thanks, that seems very reasonable to me, too.
>>
>> Are you going to pick up revitalizing this patch series or are you
>> hoping Vikas will? IIRC I was in favor of your patch but it generated
>> a whole bunch of discussion and never actually landed.
>
> I will respin it along with few other patches for pinctrl-samsung, but
> obviously not before Monday.
Sounds like a plan. Vikas: I'll assume you're going to redo this
patch atop Tomasz's once he posts up his.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] drm: Constify struct drm_fb_helper_funcs
From: Thierry Reding
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/gpu/drm/udl/udl_fb.c | 2 +-
include/drm/drm_fb_helper.h | 2 +-
17 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index fd166f532ab9..a7c947cd9386 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
return ret;
}
-static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
.gamma_set = armada_drm_crtc_gamma_set,
.gamma_get = armada_drm_crtc_gamma_get,
.fb_probe = armada_fb_probe,
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f47c27..2113894e4ff8 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16
*red, u16 *green,
*blue = ast_crtc->lut_b[regno] << 8;
}
-static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 561b84474122..17e5c17f2730 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red,
u16 *green,
*blue = regno;
}
-static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
.gamma_set = bochs_fb_gamma_set,
.gamma_get = bochs_fb_gamma_get,
.fb_probe = bochsfb_create,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 32bbba0a787b..2bd0291168e4 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
return 0;
}
-static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index f27c883be391..cb01e1606384 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
return ret;
}
-static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
+static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index d771b467cf0c..fc25fe75aa77 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -225,7 +225,7 @@ out:
return ret;
}
-static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
};
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index e7fcc148f333..76e4d777d01d 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
return psbfb_create(psb_fbdev, sizes);
}
-static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs psb_fb_helper_funcs = {
.gamma_set = psbfb_gamma_set,
.gamma_get = psbfb_gamma_get,
.fb_probe = psbfb_probe,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/dr
[PATCH v3 1/4] drm/fb-helper: Fix hpd vs. initial config races
From: Daniel Vetter
Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.
This race is especially noticable on embedded platforms where the
driver itself enables the voltage for the hdmi output, since only then
will monitors (after a bit of delay, as usual) respond by asserting
the hpd pin.
Most of the infrastructure is already there with the split-out
drm_fb_helper_init. And drm_fb_helper_initial_config already has all
the required locking to handle concurrent hpd events since
commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
Author: Daniel Vetter
Date: Thu Mar 20 14:26:35 2014 +0100
drm/fb-helper: improve drm_fb_helper_initial_config locking
The only missing bit is making drm_fb_helper_hotplug_event save
against concurrent calls of drm_fb_helper_initial_config. The only
unprotected bit is the check for fb_helper->fb.
With that drivers can first initialize the fb helper, then enabel
hotplug processing and then set up the initial config all in a
completely race-free manner. Update kerneldoc and convert i915 as a
proof of concept.
Feature requested by Thierry since his tegra driver atm reliably boots
slowly enough to misses the hotplug event for an external hdmi screen,
but also reliably boots to quickly for the hpd pin to be asserted when
the fb helper calls into the hdmi ->detect function.
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Changes in v3:
- remove an additional occurrence of i915's enable_hotplug_processing
that was introduced after the original patch
drivers/gpu/drm/drm_fb_helper.c | 11 +--
drivers/gpu/drm/i915/i915_dma.c | 3 ---
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_irq.c | 4
5 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d5d8cea1a679..13a098c9af31 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1613,8 +1613,10 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
* either the output polling work or a work item launched from the driver's
* hotplug interrupt).
*
- * Note that the driver must ensure that this is only called _after_ the fb has
- * been fully set up, i.e. after the call to drm_fb_helper_initial_config.
+ * Note that drivers may call this even before calling
+ * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This allows
+ * for a race-free fbcon setup and will make sure that the fbdev emulation will
+ * not miss any hotplug events.
*
* RETURNS:
* 0 on success and a non-zero error code otherwise.
@@ -1624,11 +1626,8 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
*fb_helper)
struct drm_device *dev = fb_helper->dev;
u32 max_width, max_height;
- if (!fb_helper->fb)
- return 0;
-
mutex_lock(&fb_helper->dev->mode_config.mutex);
- if (!drm_fb_helper_is_bound(fb_helper)) {
+ if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
mutex_unlock(&fb_helper->dev->mode_config.mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1838f8..84b55665bd87 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1377,9 +1377,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
*/
intel_fbdev_initial_config(dev);
- /* Only enable hotplug handling once the fbdev is fully set up. */
- dev_priv->enable_hotplug_processing = true;
-
drm_kms_helper_poll_init(dev);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6eb45ac7a7d5..b0955fffca98 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,7 +521,6 @@ static int i915_drm_freeze(struct drm_device *dev)
}
intel_runtime_pm_disable_interrupts(dev);
- dev_priv->enable_hotplug_processing = false;
intel_suspend_gt_powersave(dev);
@@ -659,7 +658,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
* notifications.
* */
intel_hpd_init(dev);
- dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cea59649ef2..df6a98cd702f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1404,7 +1404,6 @@ struct drm_i915_private {
u32 pipestat_irq_mask[I915_MAX_P
[PATCH v3 4/4] drm/tegra: Implement race-free hotplug detection
From: Thierry Reding
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happens
because on some boards the HDMI driver can control the regulator that
supplies the +5V pin on the HDMI connector. Therefore depending on the
timing between the initialization of the HDMI driver and the rest of
DRM, it's possible that the monitor returns the hotplug signal right
within the window where we would miss it.
Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
before at least some parts of the FB helpers have been set up.
This commit fixes this by splitting out the minimum of initialization
required to make drm_kms_helper_poll_init() work into a separate
function that can be called early. It is then safe to move all of the
poll helper initialization to an earlier point in time (before the
HDMI output driver has a chance to enable the +5V supply). That way if
the hotplug signal is returned before the initial FB helper setup, the
monitor will be forcefully detected at that point, and if the hotplug
signal is returned after that it will be properly handled by the poll
helpers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 8 ++--
drivers/gpu/drm/tegra/drm.h | 1 +
drivers/gpu/drm/tegra/fb.c | 47 ++---
3 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3396f9f6a9f7..fd736efd14bd 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -40,6 +40,12 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
drm_mode_config_init(drm);
+ err = tegra_drm_fb_prepare(drm);
+ if (err < 0)
+ return err;
+
+ drm_kms_helper_poll_init(drm);
+
err = host1x_device_init(device);
if (err < 0)
return err;
@@ -59,8 +65,6 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (err < 0)
return err;
- drm_kms_helper_poll_init(drm);
-
return 0;
}
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6b8fe9d86ed4..0d30689dff01 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -280,6 +280,7 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer
*framebuffer,
unsigned int index);
bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer);
bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
+int tegra_drm_fb_prepare(struct drm_device *drm);
int tegra_drm_fb_init(struct drm_device *drm);
void tegra_drm_fb_exit(struct drm_device *drm);
#ifdef CONFIG_DRM_TEGRA_FBDEV
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index d5d53aa79ced..fc1528e0bda1 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -271,13 +271,9 @@ static const struct drm_fb_helper_funcs
tegra_fb_helper_funcs = {
.fb_probe = tegra_fbdev_probe,
};
-static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm,
- unsigned int preferred_bpp,
- unsigned int num_crtc,
- unsigned int max_connectors)
+static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm)
{
struct tegra_fbdev *fbdev;
- int err;
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev) {
@@ -287,10 +283,21 @@ static struct tegra_fbdev *tegra_fbdev_create(struct
drm_device *drm,
drm_fb_helper_prepare(drm, &fbdev->base, &tegra_fb_helper_funcs);
+ return fbdev;
+}
+
+static int tegra_fbdev_init(struct tegra_fbdev *fbdev,
+ unsigned int preferred_bpp,
+ unsigned int num_crtc,
+ unsigned int max_connectors)
+{
+ struct drm_device *drm = fbdev->base.dev;
+ int err;
+
err = drm_fb_helper_init(drm, &fbdev->base, num_crtc, max_connectors);
if (err < 0) {
dev_err(drm->dev, "failed to initialize DRM FB helper\n");
- goto free;
+ return err;
}
err = drm_fb_helper_single_add_all_connectors(&fbdev->base);
@@ -299,21 +306,17 @@ static struct tegra_fbdev *tegra_fbdev_create(struct
drm_device *drm,
goto fini;
}
- drm_helper_disable_unused_functions(drm);
-
err = drm_fb_helper_initial_config(&fbdev->base, preferred_bpp);
if (err < 0) {
dev_err(drm->dev, "failed to set initial configuration\n");
goto fini;
}
- return fbdev;
+ return 0;
fini:
[PATCH v3 3/4] drm: Introduce drm_fb_helper_prepare()
From: Thierry Reding
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.
At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.
Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Changes in v3:
- fix inconsistency "second" -> "third" (Daniel Vetter)
Changes in v2:
- improve kernel-doc (Daniel Vetter)
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 4 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 4 ++-
drivers/gpu/drm/drm_fb_cma_helper.c | 3 +-
drivers/gpu/drm/drm_fb_helper.c | 47 ---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 +-
drivers/gpu/drm/gma500/framebuffer.c | 3 +-
drivers/gpu/drm/i915/intel_fbdev.c| 3 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 5 +++-
drivers/gpu/drm/radeon/radeon_fb.c| 4 ++-
drivers/gpu/drm/tegra/fb.c| 4 +--
drivers/gpu/drm/udl/udl_fb.c | 3 +-
include/drm/drm_fb_helper.h | 2 ++
18 files changed, 72 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index a7c947cd9386..7838e731b0de 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -149,7 +149,7 @@ int armada_fbdev_init(struct drm_device *dev)
priv->fbdev = fbh;
- fbh->funcs = &armada_fb_helper_funcs;
+ drm_fb_helper_prepare(dev, fbh, &armada_fb_helper_funcs);
ret = drm_fb_helper_init(dev, fbh, 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 2113894e4ff8..cba45c774552 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -328,8 +328,10 @@ int ast_fbdev_init(struct drm_device *dev)
return -ENOMEM;
ast->fbdev = afbdev;
- afbdev->helper.funcs = &ast_fb_helper_funcs;
spin_lock_init(&afbdev->dirty_lock);
+
+ drm_fb_helper_prepare(dev, &afbdev->helper, &ast_fb_helper_funcs);
+
ret = drm_fb_helper_init(dev, &afbdev->helper,
1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 17e5c17f2730..19cf3e9413b6 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -189,7 +189,8 @@ int bochs_fbdev_init(struct bochs_device *bochs)
{
int ret;
- bochs->fb.helper.funcs = &bochs_fb_helper_funcs;
+ drm_fb_helper_prepare(bochs->dev, &bochs->fb.helper,
+ &bochs_fb_helper_funcs);
ret = drm_fb_helper_init(bochs->dev, &bochs->fb.helper,
1, 1);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 2bd0291168e4..2a135f253e29 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -306,9 +306,11 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
return -ENOMEM;
cdev->mode_info.gfbdev = gfbdev;
- gfbdev->helper.funcs = &cirrus_fb_helper_funcs;
spin_lock_init(&gfbdev->dirty_lock);
+ drm_fb_helper_prepare(cdev->dev, &gfbdev->helper,
+ &cirrus_fb_helper_funcs);
+
ret = drm_fb_helper_init(cdev->dev, &gfbdev->helper,
cdev->num_crtc, CIRRUSFB_CONN_LIMIT);
if (ret) {
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index cb01e1606384..cc0ae047ed3b 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -354,9 +354,10 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device
*dev,
return ERR_PTR(-ENOMEM);
}
- fbdev_cma->fb_helper.funcs = &drm_fb_cma_helper_funcs;
helper = &fbdev_cma->fb_helper;
+ drm_fb_helper_prepare(dev, helper, &drm_fb_cma_helper_funcs);
+
ret = drm_fb_helper_init(dev, helper, num_cr
Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree
Tomasz and Vikas,
On Fri, Jun 27, 2014 at 5:17 AM, Tomasz Figa wrote:
> Hi Doug,
>
> On 26.06.2014 17:25, Doug Anderson wrote:
>> Tomasz,
>>
>> On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote:
>>> Hi Vikas, Doug,
>>>
>>> On 26.06.2014 11:15, Vikas Sajjan wrote:
From: Doug Anderson
The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
being reset across sleep/wake. If we don't set it to anything then
the TPM will be reset. U-Boot will detect this as invalid
and will reset the system on resume time. This GPIO can always be low
and not hurt anything. It will get pulled back high again during a
normal warm reset when it will default back to an input.
To properly preserve the TPM state across suspend/resume and to make
the chrome U-Boot happy, properly set the GPIO to mask the
reset to the TPM.
Signed-off-by: Doug Anderson
Signed-off-by: Vikas Sajjan
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..8fd990a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -87,6 +87,18 @@
pinctrl-0 = <&usb301_vbus_en>;
enable-active-high;
};
+
+ /* We need GPX0_6 to be low at sleep time; just keep it low always */
+ mask_tpm_reset_regulator: mask-tpm-reset-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "mask-tpm-reset ";
+ gpio = <&gpx0 6 0>;
+ enable-active-low;
+ regulator-boot-on;
+ regulator-always-on;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mask_tpm_reset>;
+ };
>>>
>>> I don't think this pin is supposed to be a real regulator. If I'm right,
>>> you should just add a hog for it, if you don't have a proper driver to
>>> handle it.
>>
>> Yes, I agree that it shouldn't really be a regulator, but there's not
>> a whole lot of choice. The pin needs to actually be driven low, not
>> just pulled low. Without your proposed patch (pinctrl: samsung: Allow
>> pin value to be initialized using pinfunc) I don't think it's possible
>> to actually drive a pin low with a hog. I could be wrong, though.
>>
>
> Uhm, I was convinced that this patch was already in. So I think your use
> case is definitely a good reason to get back to this patch and use the
> facility it provides to solve your problem.
Thanks, that seems very reasonable to me, too.
Are you going to pick up revitalizing this patch series or are you
hoping Vikas will? IIRC I was in favor of your patch but it generated
a whole bunch of discussion and never actually landed.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dts: Add mask-tpm-reset to the device tree
On 27.06.2014 17:10, Doug Anderson wrote:
> Tomasz and Vikas,
>
> On Fri, Jun 27, 2014 at 5:17 AM, Tomasz Figa wrote:
>> Hi Doug,
>>
>> On 26.06.2014 17:25, Doug Anderson wrote:
>>> Tomasz,
>>>
>>> On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote:
Hi Vikas, Doug,
On 26.06.2014 11:15, Vikas Sajjan wrote:
> From: Doug Anderson
>
> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
> being reset across sleep/wake. If we don't set it to anything then
> the TPM will be reset. U-Boot will detect this as invalid
> and will reset the system on resume time. This GPIO can always be low
> and not hurt anything. It will get pulled back high again during a
> normal warm reset when it will default back to an input.
>
> To properly preserve the TPM state across suspend/resume and to make
> the chrome U-Boot happy, properly set the GPIO to mask the
> reset to the TPM.
>
> Signed-off-by: Doug Anderson
> Signed-off-by: Vikas Sajjan
> ---
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 7649982..8fd990a 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -87,6 +87,18 @@
> pinctrl-0 = <&usb301_vbus_en>;
> enable-active-high;
> };
> +
> + /* We need GPX0_6 to be low at sleep time; just keep it low always
> */
> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "mask-tpm-reset ";
> + gpio = <&gpx0 6 0>;
> + enable-active-low;
> + regulator-boot-on;
> + regulator-always-on;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mask_tpm_reset>;
> + };
I don't think this pin is supposed to be a real regulator. If I'm right,
you should just add a hog for it, if you don't have a proper driver to
handle it.
>>>
>>> Yes, I agree that it shouldn't really be a regulator, but there's not
>>> a whole lot of choice. The pin needs to actually be driven low, not
>>> just pulled low. Without your proposed patch (pinctrl: samsung: Allow
>>> pin value to be initialized using pinfunc) I don't think it's possible
>>> to actually drive a pin low with a hog. I could be wrong, though.
>>>
>>
>> Uhm, I was convinced that this patch was already in. So I think your use
>> case is definitely a good reason to get back to this patch and use the
>> facility it provides to solve your problem.
>
> Thanks, that seems very reasonable to me, too.
>
> Are you going to pick up revitalizing this patch series or are you
> hoping Vikas will? IIRC I was in favor of your patch but it generated
> a whole bunch of discussion and never actually landed.
I will respin it along with few other patches for pinctrl-samsung, but
obviously not before Monday.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Remove outdated usb2 phy entry from exynos5250.dtsi
The exynos5250.dtsi has two entries for describing the usb2 phy. One for
the newer driver using the generic PHY framework and one for its
predecessor. The older node is only referenced by the arndale dts, which
seems redundant given starting from dba2f05880c the common dtsi also
includes the phy entries.
Signed-off-by: Sjoerd Simons
---
arch/arm/boot/dts/exynos5250-arndale.dts | 4
arch/arm/boot/dts/exynos5250.dtsi| 15 ---
2 files changed, 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..dad8f9b 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -570,8 +570,4 @@
connect-gpios = <&gpd1 7 1>;
};
};
-
- usb@1211 {
- usb-phy = <&usb2_phy>;
- };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 834fb5a..7c545d50 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -600,21 +600,6 @@
};
};
- usb2_phy: usbphy@1213 {
- compatible = "samsung,exynos5250-usb2phy";
- reg = <0x1213 0x100>;
- clocks = <&clock CLK_FIN_PLL>, <&clock CLK_USB2>;
- clock-names = "ext_xtal", "usbhost";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- usbphy-sys {
- reg = <0x10040704 0x8>,
- <0x10050230 0x4>;
- };
- };
-
usb2_phy_gen: phy@1213 {
compatible = "samsung,exynos5250-usb2-phy";
reg = <0x1213 0x100>;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman wrote: > On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera wrote: > >> Would you please provide me the environment setting of your u-boot? >> U-boot environment on my board has been over-written, I would like to >> set it same as yours and try to reproduce the issue at my end. With only >> 'sound init', I don't seem to hit this issue anymore. > > Attached is a full boot log using v3.16-rc2 with my patch adding > CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch. In the > boot log, you'll see the output of 'printenv' inside u-boot where the > environment is dumped. Oops, I sent you a boot log for the octa board. Here's the one for peach-pi with the same kernel (built with upstream exynos_defconfig) Kevin boot-chromebook2.log.gz Description: GNU Zip compressed data
Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera wrote: > Would you please provide me the environment setting of your u-boot? > U-boot environment on my board has been over-written, I would like to > set it same as yours and try to reproduce the issue at my end. With only > 'sound init', I don't seem to hit this issue anymore. Attached is a full boot log using v3.16-rc2 with my patch adding CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch. In the boot log, you'll see the output of 'printenv' inside u-boot where the environment is dumped. Hope that helps, Kevin boot-octa.log.gz Description: GNU Zip compressed data
Re: [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
On 27.06.2014 15:02, Ajay kumar wrote:
> Hi Andrej,
>
> On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda wrote:
>> On 06/27/2014 01:48 PM, Ajay kumar wrote:
>>> Hi Andrej,
>>>
>>> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda wrote:
Hi Ajay,
+CC DT
On 06/27/2014 12:12 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be set if we are using DP.
>
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/samsung-fimd.txt |1 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
>
> include/video/samsung_fimd.h |4
> 3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> index 2dad41b..12f3d7a 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -41,6 +41,7 @@ Optional Properties:
> - samsung,power-domain: a phandle to FIMD power domain node.
> - samsung,invert-vden: video enable signal is inverted
> - samsung,invert-vclk: video clock signal is inverted
> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1,
> DP=2)
There is no point in introducing this property. Exynos DRM have already
logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
reused to determine display type. It can be done even without any
additional callbacks, just by checking if there is connector of
DRM_MODE_CONNECTOR_eDP type connected to fimd.
>>> The mapping between crtc(struct exynos_drm_manager) and encoder(struct
>>> exynos_drm_display)
>>> in exynos drm happens by matching the exynos_drm_output_type variable in
>>> each
>>> structure.
>>> exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
>>> FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
>>> and both DP and MIPI statically choose the same enum
>>> EXYNOS_DISPLAY_TYPE_LCD,
>>> as output type.
>>> So, we cannot use that logic to differentiate between DP/MIPI DSI.
>>>
>>> Also, checking based on connector type doesn't hold good.
>>> The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
>>> DP->LVDS or MIPI->LVDS panels!
>>
>> True, I forgot about bridges. So additional callback/field is necessary.
>> See below.
>>
>>>
>>> Thanks and regards,
>>> Ajay Kumar
>>>
Regards
Andrzej
> - display-timings: timing settings for FIMD, as described in document
> [1].
> Can be used in case timings cannot be provided otherwise
> or to override timings provided by the panel.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..aa74e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
> unsigned int has_shadowcon:1;
> unsigned int has_clksel:1;
> unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,13 @@ static struct fimd_driver_data
> exynos4_fimd_driver_data = {
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> .timing_base = 0x2,
> .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
> +};
> +
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DSI,
> + EXYNOS_FIMD_OUTPUT_DP,
> };
>
> struct fimd_win_data {
> @@ -125,6 +133,8 @@ struct fimd_context {
> struct exynos_drm_panel_info panel;
> struct fimd_driver_data *driver_data;
> struct exynos_drm_display *display;
> +
> + enum exynos_fimd_output_type exynos_fimd_output_type;
> };
>
> static const struct of_device_id fimd_driver_dt_match[] = {
> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager
> *mgr)
> if (clkdiv > 1)
> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>
> + if (ctx->driver_data->has_dp_clkcon &&
> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
> writel(val, ctx->regs + VIDCON0);
>>
>> New code should not split VIDCON0 related code.It should be moved few
>> lines above or few lines below.
> Ok, for better readability.
>
>> Anyway this code should be rather placed in power related functions of
>> dp encoder, as it enables dp. The only question
>> is if DP_CLKCON update
Re: [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
Hi Andrej,
On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda wrote:
> On 06/27/2014 01:48 PM, Ajay kumar wrote:
>> Hi Andrej,
>>
>> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda wrote:
>>> Hi Ajay,
>>>
>>> +CC DT
>>>
>>> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be set if we are using DP.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/samsung-fimd.txt |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
include/video/samsung_fimd.h |4
3 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..12f3d7a 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -41,6 +41,7 @@ Optional Properties:
- samsung,power-domain: a phandle to FIMD power domain node.
- samsung,invert-vden: video enable signal is inverted
- samsung,invert-vclk: video clock signal is inverted
+- samsung,output-type: Type of display output interface(DPI=0, DSI=1,
DP=2)
>>> There is no point in introducing this property. Exynos DRM have already
>>> logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
>>> reused to determine display type. It can be done even without any
>>> additional callbacks, just by checking if there is connector of
>>> DRM_MODE_CONNECTOR_eDP type connected to fimd.
>> The mapping between crtc(struct exynos_drm_manager) and encoder(struct
>> exynos_drm_display)
>> in exynos drm happens by matching the exynos_drm_output_type variable in each
>> structure.
>> exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
>> FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
>> and both DP and MIPI statically choose the same enum EXYNOS_DISPLAY_TYPE_LCD,
>> as output type.
>> So, we cannot use that logic to differentiate between DP/MIPI DSI.
>>
>> Also, checking based on connector type doesn't hold good.
>> The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
>> DP->LVDS or MIPI->LVDS panels!
>
> True, I forgot about bridges. So additional callback/field is necessary.
> See below.
>
>>
>> Thanks and regards,
>> Ajay Kumar
>>
>>> Regards
>>> Andrzej
>>>
- display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..aa74e90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_dp_clkcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data
= {
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+ .has_dp_clkcon = 1,
+};
+
+enum exynos_fimd_output_type {
+ EXYNOS_FIMD_OUTPUT_DPI,
+ EXYNOS_FIMD_OUTPUT_DSI,
+ EXYNOS_FIMD_OUTPUT_DP,
};
struct fimd_win_data {
@@ -125,6 +133,8 @@ struct fimd_context {
struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
struct exynos_drm_display *display;
+
+ enum exynos_fimd_output_type exynos_fimd_output_type;
};
static const struct of_device_id fimd_driver_dt_match[] = {
@@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager
*mgr)
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx->driver_data->has_dp_clkcon &&
+ ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
+ writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
+
writel(val, ctx->regs + VIDCON0);
>
> New code should not split VIDCON0 related code.It should be moved few
> lines above or few lines below.
Ok, for better readability.
> Anyway this code should be rather placed in power related functions of
> dp encoder, as it enables dp. The only question
> is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
> solution of the whole problem
I will check this.
> seems to be simple:
> - fimd should provide function fimd_set_dp_clk_gate or st
Re: [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
On 06/27/2014 01:48 PM, Ajay kumar wrote:
> Hi Andrej,
>
> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda wrote:
>> Hi Ajay,
>>
>> +CC DT
>>
>> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
>>> Add the missing setting for DP CLKCON register.
>>>
>>> This register is present on Exynos5 based FIMD controllers,
>>> and needs to be set if we are using DP.
>>>
>>> Signed-off-by: Ajay Kumar
>>> ---
>>> .../devicetree/bindings/video/samsung-fimd.txt |1 +
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
>>>
>>> include/video/samsung_fimd.h |4
>>> 3 files changed, 28 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> index 2dad41b..12f3d7a 100644
>>> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> @@ -41,6 +41,7 @@ Optional Properties:
>>> - samsung,power-domain: a phandle to FIMD power domain node.
>>> - samsung,invert-vden: video enable signal is inverted
>>> - samsung,invert-vclk: video clock signal is inverted
>>> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
>> There is no point in introducing this property. Exynos DRM have already
>> logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
>> reused to determine display type. It can be done even without any
>> additional callbacks, just by checking if there is connector of
>> DRM_MODE_CONNECTOR_eDP type connected to fimd.
> The mapping between crtc(struct exynos_drm_manager) and encoder(struct
> exynos_drm_display)
> in exynos drm happens by matching the exynos_drm_output_type variable in each
> structure.
> exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
> FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
> and both DP and MIPI statically choose the same enum EXYNOS_DISPLAY_TYPE_LCD,
> as output type.
> So, we cannot use that logic to differentiate between DP/MIPI DSI.
>
> Also, checking based on connector type doesn't hold good.
> The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
> DP->LVDS or MIPI->LVDS panels!
True, I forgot about bridges. So additional callback/field is necessary.
See below.
>
> Thanks and regards,
> Ajay Kumar
>
>> Regards
>> Andrzej
>>
>>> - display-timings: timing settings for FIMD, as described in document [1].
>>> Can be used in case timings cannot be provided otherwise
>>> or to override timings provided by the panel.
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 33161ad..aa74e90 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>> unsigned int has_shadowcon:1;
>>> unsigned int has_clksel:1;
>>> unsigned int has_limited_fmt:1;
>>> + unsigned int has_dp_clkcon:1;
>>> };
>>>
>>> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>>> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data
>>> = {
>>> static struct fimd_driver_data exynos5_fimd_driver_data = {
>>> .timing_base = 0x2,
>>> .has_shadowcon = 1,
>>> + .has_dp_clkcon = 1,
>>> +};
>>> +
>>> +enum exynos_fimd_output_type {
>>> + EXYNOS_FIMD_OUTPUT_DPI,
>>> + EXYNOS_FIMD_OUTPUT_DSI,
>>> + EXYNOS_FIMD_OUTPUT_DP,
>>> };
>>>
>>> struct fimd_win_data {
>>> @@ -125,6 +133,8 @@ struct fimd_context {
>>> struct exynos_drm_panel_info panel;
>>> struct fimd_driver_data *driver_data;
>>> struct exynos_drm_display *display;
>>> +
>>> + enum exynos_fimd_output_type exynos_fimd_output_type;
>>> };
>>>
>>> static const struct of_device_id fimd_driver_dt_match[] = {
>>> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>> if (clkdiv > 1)
>>> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>>
>>> + if (ctx->driver_data->has_dp_clkcon &&
>>> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>>> +
>>> writel(val, ctx->regs + VIDCON0);
New code should not split VIDCON0 related code. It should be moved few
lines above or few lines below.
Anyway this code should be rather placed in power related functions of
dp encoder, as it enables dp. The only question
is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
solution of the whole problem
seems to be simple:
- fimd should provide function fimd_set_dp_clk_gate or sth similar,
- this function should be called in exynos_dp_poweron/exynos_dp_poweroff.
I hope I have not missed anything this time.
Regards
Andrzej
>>> }
>>>
>>> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
>>> struct devi
Re: [PATCH v2 09/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC
On Wed, Jun 18, 2014 at 11:14:06AM -0700, Doug Anderson wrote: > From: Bill Richardson > > When communicating with the EC, the cmd_xfer() function should return the > number of bytes it received from the EC, or negative on error. > > Signed-off-by: Bill Richardson > Signed-off-by: Doug Anderson > Acked-by: Lee Jones > Reviewed-by: Simon Glass For the I2C part: Acked-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH v2 07/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
On Wed, Jun 18, 2014 at 11:14:04AM -0700, Doug Anderson wrote: > From: Bill Richardson > > Remove the three wrapper functions that talk to the EC without passing all > the desired arguments and just use the underlying communication function > that passes everything in a struct intead. > > This is internal code refactoring only. Nothing should change. > > Signed-off-by: Bill Richardson > Signed-off-by: Doug Anderson > Acked-by: Lee Jones > Reviewed-by: Simon Glass For the I2C part: Acked-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree
Hi Doug,
On 26.06.2014 17:25, Doug Anderson wrote:
> Tomasz,
>
> On Thu, Jun 26, 2014 at 2:52 AM, Tomasz Figa wrote:
>> Hi Vikas, Doug,
>>
>> On 26.06.2014 11:15, Vikas Sajjan wrote:
>>> From: Doug Anderson
>>>
>>> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
>>> being reset across sleep/wake. If we don't set it to anything then
>>> the TPM will be reset. U-Boot will detect this as invalid
>>> and will reset the system on resume time. This GPIO can always be low
>>> and not hurt anything. It will get pulled back high again during a
>>> normal warm reset when it will default back to an input.
>>>
>>> To properly preserve the TPM state across suspend/resume and to make
>>> the chrome U-Boot happy, properly set the GPIO to mask the
>>> reset to the TPM.
>>>
>>> Signed-off-by: Doug Anderson
>>> Signed-off-by: Vikas Sajjan
>>> ---
>>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 20
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> index 7649982..8fd990a 100644
>>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> @@ -87,6 +87,18 @@
>>> pinctrl-0 = <&usb301_vbus_en>;
>>> enable-active-high;
>>> };
>>> +
>>> + /* We need GPX0_6 to be low at sleep time; just keep it low always */
>>> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "mask-tpm-reset ";
>>> + gpio = <&gpx0 6 0>;
>>> + enable-active-low;
>>> + regulator-boot-on;
>>> + regulator-always-on;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mask_tpm_reset>;
>>> + };
>>
>> I don't think this pin is supposed to be a real regulator. If I'm right,
>> you should just add a hog for it, if you don't have a proper driver to
>> handle it.
>
> Yes, I agree that it shouldn't really be a regulator, but there's not
> a whole lot of choice. The pin needs to actually be driven low, not
> just pulled low. Without your proposed patch (pinctrl: samsung: Allow
> pin value to be initialized using pinfunc) I don't think it's possible
> to actually drive a pin low with a hog. I could be wrong, though.
>
Uhm, I was convinced that this patch was already in. So I think your use
case is definitely a good reason to get back to this patch and use the
facility it provides to solve your problem.
>
> So I think our options are:
>
> * Begrudgingly use the regulator this way.
>
> * Re-propose your pinctrl patch and use hogs.
I'd prefer this one, as stated above. I think the reasons are obvious:
no made up devices and re-using infrastructure useful for other purposes
as well.
>
> * Implement a tiny driver that will just hold a GPIO in a certain
> state and instantiate that driver here.
>
> * Decide that really the firmware should have set this pin and that if
> someone wants suspend/resume to work then they'll just have to update
> their firmware. Queue the debate about what firmware vs. kernel's job
> is and commence yelling about the fact that it's hard to get an
> official RW firmware update approved. Note: I'm not quite sure why I
> didn't have the firmware init this GPIO to begin with (so that if the
> kernel didn't do anything it would just work). Probably just me being
> stupid.
>
Right, ideally the firmware should be making operating system's life
easier not harder, but we all know that even if there are examples of
good firmware, there will always be the opposite as well... So the
kernel should be able to work anyway.
>
> Ah, one other thing that could justify this being its own special
> driver (though you might be able to use the regulator framework for it
> too?). Technically you'll save a tiny amount of power in the system
> if you leave this GPIO high while the system is running and only drive
> it low when the system goes to suspend. That's because there's a
> pretty strong external pullup on this pin. The amount of power is
> probably not noticeable and the savings is only possible when the
> system is on (and in high power state) anyway, but...
This could be also handled by adding a sleep hog, i.e. "sleep" state for
the pinctrl device itself and adding proper suspend/resume callbacks to
the pinctrl-samsung driver (I'm not sure whether a call to
pinctrl_select_state() would work in syscore ops).
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
Hi Andrej,
On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda wrote:
> Hi Ajay,
>
> +CC DT
>
> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be set if we are using DP.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> .../devicetree/bindings/video/samsung-fimd.txt |1 +
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
>>
>> include/video/samsung_fimd.h |4
>> 3 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> index 2dad41b..12f3d7a 100644
>> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> @@ -41,6 +41,7 @@ Optional Properties:
>> - samsung,power-domain: a phandle to FIMD power domain node.
>> - samsung,invert-vden: video enable signal is inverted
>> - samsung,invert-vclk: video clock signal is inverted
>> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
>
> There is no point in introducing this property. Exynos DRM have already
> logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
> reused to determine display type. It can be done even without any
> additional callbacks, just by checking if there is connector of
> DRM_MODE_CONNECTOR_eDP type connected to fimd.
The mapping between crtc(struct exynos_drm_manager) and encoder(struct
exynos_drm_display)
in exynos drm happens by matching the exynos_drm_output_type variable in each
structure.
exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
and both DP and MIPI statically choose the same enum EXYNOS_DISPLAY_TYPE_LCD,
as output type.
So, we cannot use that logic to differentiate between DP/MIPI DSI.
Also, checking based on connector type doesn't hold good.
The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
DP->LVDS or MIPI->LVDS panels!
Thanks and regards,
Ajay Kumar
>
> Regards
> Andrzej
>
>> - display-timings: timing settings for FIMD, as described in document [1].
>> Can be used in case timings cannot be provided otherwise
>> or to override timings provided by the panel.
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 33161ad..aa74e90 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>> unsigned int has_shadowcon:1;
>> unsigned int has_clksel:1;
>> unsigned int has_limited_fmt:1;
>> + unsigned int has_dp_clkcon:1;
>> };
>>
>> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data =
>> {
>> static struct fimd_driver_data exynos5_fimd_driver_data = {
>> .timing_base = 0x2,
>> .has_shadowcon = 1,
>> + .has_dp_clkcon = 1,
>> +};
>> +
>> +enum exynos_fimd_output_type {
>> + EXYNOS_FIMD_OUTPUT_DPI,
>> + EXYNOS_FIMD_OUTPUT_DSI,
>> + EXYNOS_FIMD_OUTPUT_DP,
>> };
>>
>> struct fimd_win_data {
>> @@ -125,6 +133,8 @@ struct fimd_context {
>> struct exynos_drm_panel_info panel;
>> struct fimd_driver_data *driver_data;
>> struct exynos_drm_display *display;
>> +
>> + enum exynos_fimd_output_type exynos_fimd_output_type;
>> };
>>
>> static const struct of_device_id fimd_driver_dt_match[] = {
>> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>> if (clkdiv > 1)
>> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>
>> + if (ctx->driver_data->has_dp_clkcon &&
>> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>> +
>> writel(val, ctx->regs + VIDCON0);
>> }
>>
>> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> struct fimd_context *ctx;
>> struct resource *res;
>> + u32 fimd_output_type;
>> int ret = -EINVAL;
>>
>> ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
>> @@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
>> ctx->vidcon1 |= VIDCON1_INV_VDEN;
>> if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
>> ctx->vidcon1 |= VIDCON1_INV_VCLK;
>> + if (!of_property_read_u32(dev->of_node, "samsung,output-type",
>> + &fimd_output_type)) {
>> + if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
>> + (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
>> + dev_err(dev, "invalid output type for
Re: [PATCHv5 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
Hi Chanwoo, On 27.06.2014 06:30, Chanwoo Choi wrote: > Changes from v4: > - Use 'exynos_adc_data' structure instead of 'exynos_adc_ops' structure > and remove enum variable of ADC version > - Fix wrong name of special clock (sclk_tsadc -> sclk_adc) > - Add reviewed message by Naveen Krishna Chatradhi > - Add functions for ADC clock control > > Changes from v3: > - Add new 'exynos_adc_ops' structure to improve readability according to > Tomasz Figa comment[1] > [1] https://lkml.org/lkml/2014/4/16/238 > - Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC > - Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file > > Changes from v2: > - Check return value of clock function to deal with error exception > - Fix minor coding style to improve readability > > Changes from v1: > - Add new "samsung,exynos-adc-v3" compatible to support Exynos3250 ADC > - Add a patch about DT binding documentation > > Chanwoo Choi (4): > iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability > iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC > iio: devicetree: Add DT binding documentation for Exynos3250 ADC > ARM: dts: Fix wrong compatible string for Exynos3250 ADC > > .../devicetree/bindings/arm/samsung/exynos-adc.txt | 26 +- > arch/arm/boot/dts/exynos3250.dtsi | 4 +- > drivers/iio/adc/exynos_adc.c | 326 > +++-- > 3 files changed, 268 insertions(+), 88 deletions(-) > For the whole series: Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
Hi Ajay,
+CC DT
On 06/27/2014 12:12 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be set if we are using DP.
>
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/samsung-fimd.txt |1 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
>
> include/video/samsung_fimd.h |4
> 3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> index 2dad41b..12f3d7a 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -41,6 +41,7 @@ Optional Properties:
> - samsung,power-domain: a phandle to FIMD power domain node.
> - samsung,invert-vden: video enable signal is inverted
> - samsung,invert-vclk: video clock signal is inverted
> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
There is no point in introducing this property. Exynos DRM have already
logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
reused to determine display type. It can be done even without any
additional callbacks, just by checking if there is connector of
DRM_MODE_CONNECTOR_eDP type connected to fimd.
Regards
Andrzej
> - display-timings: timing settings for FIMD, as described in document [1].
> Can be used in case timings cannot be provided otherwise
> or to override timings provided by the panel.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..aa74e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
> unsigned int has_shadowcon:1;
> unsigned int has_clksel:1;
> unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> .timing_base = 0x2,
> .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
> +};
> +
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DSI,
> + EXYNOS_FIMD_OUTPUT_DP,
> };
>
> struct fimd_win_data {
> @@ -125,6 +133,8 @@ struct fimd_context {
> struct exynos_drm_panel_info panel;
> struct fimd_driver_data *driver_data;
> struct exynos_drm_display *display;
> +
> + enum exynos_fimd_output_type exynos_fimd_output_type;
> };
>
> static const struct of_device_id fimd_driver_dt_match[] = {
> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> if (clkdiv > 1)
> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>
> + if (ctx->driver_data->has_dp_clkcon &&
> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
> writel(val, ctx->regs + VIDCON0);
> }
>
> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct fimd_context *ctx;
> struct resource *res;
> + u32 fimd_output_type;
> int ret = -EINVAL;
>
> ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
> @@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
> ctx->vidcon1 |= VIDCON1_INV_VDEN;
> if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
> ctx->vidcon1 |= VIDCON1_INV_VCLK;
> + if (!of_property_read_u32(dev->of_node, "samsung,output-type",
> + &fimd_output_type)) {
> + if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
> + (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
> + dev_err(dev, "invalid output type for FIMD\n");
> + else
> + ctx->exynos_fimd_output_type = fimd_output_type;
> + }
>
> ctx->bus_clk = devm_clk_get(dev, "fimd");
> if (IS_ERR(ctx->bus_clk)) {
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
> #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
> #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
> /* Notes on per-window bpp settings
> *
> * Value Win0 Win1 Win2 Win3 Win 4
>
--
To unsubscribe from
RE: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
On Fri, June 27, 2014, Doug Anderson wrote:
> Seungwon,
>
> On Thu, Jun 26, 2014 at 3:30 AM, Seungwon Jeon wrote:
> > Hi Doug,
> >
> > On Thu, June 26, 2014, Doug Anderson wrote:
> >> Seungwon,
> >>
> >> On Wed, Jun 25, 2014 at 4:18 AM, Seungwon Jeon
> >> wrote:
> >> >> >> + case MMC_POWER_ON:
> >> >> >> + if (!IS_ERR(mmc->supply.vqmmc) &&
> >> >> >> + !test_bit(DW_MMC_IO_POWERED,
> >> >> >> &slot->flags)) {
> >> > You can use regulator_is_enabled() instead of flag bit,
> >> > DW_MMC_IO_POWERED.
> >>
> >> I'd be a little worried about regulator_is_enabled() since regulators
> >> are reference counted. What if someone else is sharing this
> >> regulator? The regulator might happen to be enabled when you check it
> >> but unless you add your own dw_mmc reference count they might turn it
> >> off.
> > Cool, that's a possibility. Some assumption may need.
> > If mmc's core can guarantee its balance, I think we don't need to consider
> > some flag.
>
> I notice that the mmc core seems to keep a flag itself for vdd (the
> mmc->regulator_enabled flag). That would imply that the core thought
> it was important to have the extra flag and that we should keep our
> own flag for vqmmc.
Ok, Good.
Thanks,
Seungwon Jeon
>
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 7/7] ARM: dts: Add FIMD output property for arndale
+DT mailing list
On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar wrote:
> Set FIMD output type for arndale as DP.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index d0de1f5..e803183 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -540,6 +540,7 @@
>
> fimd: fimd@1440 {
> status = "okay";
> + samsung,output-type = <2>;
> display-timings {
> native-mode = <&timing0>;
> timing0: timing@0 {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: dw_mmc: Support voltage changes
Hi Yuvaraj,
On Fri, June 27, 2014, Yuvaraj Kumar wrote:
> On Thu, Jun 26, 2014 at 10:20 PM, Doug Anderson wrote:
> > Seungwon,
> >
> > On Thu, Jun 26, 2014 at 3:41 AM, Seungwon Jeon wrote:
> >> On Thu, June 26, 2014, Doug Anderson wrote:
> >>> Seungwon,
> >>>
> >>> On Wed, Jun 25, 2014 at 6:08 AM, Seungwon Jeon
> >>> wrote:
> >>> > On Mon, June 23, 2014, Yuvaraj Kumar C D wrote:
> >>> >> Subject: [PATCH 3/3] mmc: dw_mmc: Support voltage changes
> >>> >>
> >>> >> From: Doug Anderson
> >>> >>
> >>> >> For UHS cards we need the ability to switch voltages from 3.3V to
> >>> >> 1.8V. Add support to the dw_mmc driver to handle this. Note that
> >>> >> dw_mmc needs a little bit of extra code since the interface needs a
> >>> >> special bit programmed to the CMD register while CMD11 is progressing.
> >>> >> This means adding a few extra states to the state machine to track.
> >>> >
> >>> > Overall new additional states makes it complicated.
> >>> > Can we do that in other way?
> >>>
> >>> That was the best I was able to figure out when I thought this
> >>> through. If you have ideas for doing it another way I'd imagine that
> >>> Yuvaraj would be happy to take your feedback.
> >> Let's clean up SDMMC_CMD_VOLT_SWITCH.
> >> In turn, we may remove state-handling simply.
> >>
> >>>
> >>>
> >>> >> Signed-off-by: Doug Anderson
> >>> >> Signed-off-by: Yuvaraj Kumar C D
> >>> >>
> >>> >> ---
> >>> >> drivers/mmc/host/dw_mmc.c | 145
> >>> >> +---
> >>> >> drivers/mmc/host/dw_mmc.h |5 +-
> >>> >> include/linux/mmc/dw_mmc.h |2 +
> >>> >> 3 files changed, 142 insertions(+), 10 deletions(-)
> >>> >>
> >>> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> >>> >> index e034bce..38eb548 100644
> >>> >> --- a/drivers/mmc/host/dw_mmc.c
> >>> >> +++ b/drivers/mmc/host/dw_mmc.c
> >>> >> @@ -29,6 +29,7 @@
> >>> >> #include
> >>> >> #include
> >>> >> #include
> >>> >> +#include
> >>> >> #include
> >>> >> #include
> >>> >> #include
> >>> >> @@ -235,10 +236,13 @@ err:
> >>> >> }
> >>> >> #endif /* defined(CONFIG_DEBUG_FS) */
> >>> >>
> >>> >> +static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
> >>> >> +
> >>> >> static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct
> >>> >> mmc_command *cmd)
> >>> >> {
> >>> >> struct mmc_data *data;
> >>> >> struct dw_mci_slot *slot = mmc_priv(mmc);
> >>> >> + struct dw_mci *host = slot->host;
> >>> >> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
> >>> >> u32 cmdr;
> >>> >> cmd->error = -EINPROGRESS;
> >>> >> @@ -254,6 +258,32 @@ static u32 dw_mci_prepare_command(struct mmc_host
> >>> >> *mmc, struct mmc_command
> >>> *cmd)
> >>> >> else if (cmd->opcode != MMC_SEND_STATUS && cmd->data)
> >>> >> cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
> >>> >>
> >>> >> + if (cmd->opcode == SD_SWITCH_VOLTAGE) {
> >>> >> + u32 clk_en_a;
> >>> >> +
> >>> >> + /* Special bit makes CMD11 not die */
> >>> >> + cmdr |= SDMMC_CMD_VOLT_SWITCH;
> >>> >> +
> >>> >> + /* Change state to continue to handle CMD11 weirdness */
> >>> >> + WARN_ON(slot->host->state != STATE_SENDING_CMD);
> >>> >> + slot->host->state = STATE_SENDING_CMD11;
> >>> >> +
> >>> >> + /*
> >>> >> + * We need to disable clock stop while doing voltage
> >>> >> switch
> >>> >> + * according to 7.4.1.2 Voltage Switch Normal Scenario.
> >>> >> + *
> >>> >> + * It's assumed that by the next time the CLKENA is
> >>> >> updated
> >>> >> + * (when we set the clock next) that the voltage change
> >>> >> will
> >>> >> + * be over, so we don't bother setting any bits to
> >>> >> synchronize
> >>> >> + * with dw_mci_setup_bus().
> >>> >> + */
> >>> >> + clk_en_a = mci_readl(host, CLKENA);
> >>> >> + clk_en_a &= ~(SDMMC_CLKEN_LOW_PWR << slot->id);
> >>> >> + mci_writel(host, CLKENA, clk_en_a);
> >>> >> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> >>> >> + SDMMC_CMD_PRV_DAT_WAIT, 0);
> >>> > dw_mci_disable_low_power() can be used here.
> >>>
> >>> Ah. I guess we don't have that locally anymore. Locally we have
> >>> variants on:
> >> I'm checking on cjb/mmc branch.
> >>
> >>> * https://patchwork.kernel.org/patch/3070311/
> >>> * https://patchwork.kernel.org/patch/3070251/
> >>> * https://patchwork.kernel.org/patch/3070221/
> >>>
> >>> ...which removed that function. ...but I guess upstream never picked
> >>> up those patches, huh? Looking back it looks like you had some
> >>> feedback and it needed another spin but somehow fell off my plate. :(
> >>>
> >>> Maybe this is something Yuvaraj would like to pick up?
> >> It's long ago. I remember that there is no progress since my last comment.
> >> In case of patch "
Re: [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420
+DT mailing list
On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar wrote:
> Set FIMD output type for smdk5420 as DP.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5420-smdk5420.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 6052aa9..5f05a19 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -120,6 +120,7 @@
>
> fimd@1440 {
> status = "okay";
> + samsung,output-type = <2>;
> display-timings {
> native-mode = <&timing0>;
> timing0: timing@0 {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 5/7] ARM: dts: Add FIMD output property for smdk5250
+DT mailing list
On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar wrote:
> Set FIMD output type for smdk5250 as DP.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5250-smdk5250.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index a794a70..ed28efb 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -382,6 +382,7 @@
>
> fimd@1440 {
> status = "okay";
> + samsung,output-type = <2>;
> display-timings {
> native-mode = <&timing0>;
> timing0: timing@0 {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 3/7] ARM: dts: Add FIMD output property for peach_pit
+DT mailing list
On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar wrote:
> Set FIMD output type for peach_pit as DP.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 1c5b8f9..164f523 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -255,6 +255,7 @@
> &fimd {
> status = "okay";
> samsung,invert-vclk;
> + samsung,output-type = <2>;
> };
>
> &dp {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/7] ARM: dts: Add FIMD output property for snow
+DT mailing list
On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar wrote:
> Set FIMD output type for snow as DP.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5250-snow.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 079fdf9..dc3ae9c 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -400,6 +400,7 @@
> fimd@1440 {
> status = "okay";
> samsung,invert-vclk;
> + samsung,output-type = <2>;
> };
>
> dp-controller@145B {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 4/7] ARM: dts: Add FIMD output property for peach_pi
+DT mailing list
On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar wrote:
> Set FIMD output type for peach_pi as DP.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5800-peach-pi.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index f3af207..21e2de2 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -205,6 +205,7 @@
> &fimd {
> status = "okay";
> samsung,invert-vclk;
> + samsung,output-type = <2>;
> };
>
> &hsi2c_9 {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
On Thu, Jun 26, 2014 at 9:48 PM, Doug Anderson wrote:
> Yuvaraj,
>
> On Thu, Jun 26, 2014 at 4:21 AM, Yuvaraj Kumar wrote:
>> Doug
>>
>> On Tue, Jun 24, 2014 at 11:30 PM, Doug Anderson
>> wrote:
>>> Yuvaraj,
>>>
>>> On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D
>>> wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D
---
drivers/mmc/host/dw_mmc.c | 71
++---
drivers/mmc/host/dw_mmc.h |2 ++
2 files changed, 36 insertions(+), 37 deletions(-)
>>>
>>> Perhaps you could CC me on the whole series for the next version since
>>> I was involved in privately reviewing previous versions?
>> It was just accidental missing you in the CC .Surely i will add you in
>> CC for next versions.
>>>
>>> Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
>>>
>>>
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..f5cabce 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
u32 regs;
+ int ret;
switch (ios->bus_width) {
case MMC_BUS_WIDTH_4:
@@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios->power_mode) {
case MMC_POWER_UP:
+ if ((!IS_ERR(mmc->supply.vmmc)) &&
+ !test_bit(DW_MMC_CARD_POWERED,
&slot->flags)) {
+ ret = regulator_enable(mmc->supply.vmmc);
+ if (!ret)
+ set_bit(DW_MMC_CARD_POWERED, &slot->flags);
+ }
>>>
>>> As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
>>> different times.
>> As you can see people's have different opinion on this.When i had a
>> look at the other drivers in the subsystem which does in the same flow
>> as above.However i will change in the next version.
>
> Given my self proclaimed lack of SD/MMC knowledge, if others have a
> good reason for doing them separate then you should do it that way.
> So far I haven't heard that reason but I certainly could be wrong.
>
>
@@ -225,6 +225,8 @@ struct dw_mci_slot {
unsigned long flags;
#define DW_MMC_CARD_PRESENT0
#define DW_MMC_CARD_NEED_INIT 1
+#define DW_MMC_CARD_POWERED2
+#define DW_MMC_IO_POWERED 3
>>>
>>> I don't really think you should have two bits here. From my
>>> understanding of SD cards there should be very little reason to have
>>> vqmmc and vmmc not powered at the same time.
>> I think if i can use mmc_regulator_set_ocr(), we don't need additional
>> flag.But for tps65090 mmc_regulator_get_ocr() and
>> mmc_regulator_set_ocr() is failing as its a fixed-regulator.
>
> Can you explain more about what's failing? It sure looks like mmc
> core is supposed to handle this given comments below
>
> /*
> * If we're using a fixed/static regulator, don't call
> * regulator_set_voltage; it would fail.
> */
tps65090 driver does not register through fixed regulator framework.It
uses normal regulator framework and supports only
enable/disable/is_enabled callbacks.Also it lacks certain callbacks
for list_voltage, get_voltage ,set_voltage etc.
[2.306476] dwmmc_exynos 1222.mmc: Failed getting OCR mask: -22
[2.393403] dwmmc_exynos 1222.mmc: could not set regulator OCR (-22)
For the above reason,regulator framework treats fet4 as unused
regulator and disables the vmmc regulator.
> voltage = regulator_get_voltage(supply);
>
> if (!regulator_can_change_voltage(supply))
> min_uV = max_uV = voltage;
>
>
> -Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 0/7] drm/exynos: Support DP CLKCON register in FIMD driver
On Fri, Jun 27, 2014 at 11:24:58AM +0100, Inki Dae wrote: > > + DT mailing list Thanks for the Cc. Can we get the rest of the series? Judging a series based on its diffstat alone is a little hard... Or is my mailbox filtering hiding the rest of these from me? Any reason for not Ccing lakml? Mark. > On 2014년 06월 27일 19:12, Ajay Kumar wrote: > > This series is based on exynos-drm-next branch of Inki Dae's tree at: > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > > > Changes since V2: > > Add DT property to know the type of FIMD output interface > > as per Inki's suggestion. > > Add samsung,output-type DT property in FIMD node for all boards > > supporting DP interface. > > > > Ajay Kumar (7): > > [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver > > [PATCH V3 2/7] ARM: dts: Add FIMD output property for snow > > [PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit > > [PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi > > [PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250 > > [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420 > > [PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale > > > > .../devicetree/bindings/video/samsung-fimd.txt |1 + > > arch/arm/boot/dts/exynos5250-arndale.dts |1 + > > arch/arm/boot/dts/exynos5250-smdk5250.dts |1 + > > arch/arm/boot/dts/exynos5250-snow.dts |1 + > > arch/arm/boot/dts/exynos5420-peach-pit.dts |1 + > > arch/arm/boot/dts/exynos5420-smdk5420.dts |1 + > > arch/arm/boot/dts/exynos5800-peach-pi.dts |1 + > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23 > > > > include/video/samsung_fimd.h |4 > > 9 files changed, 34 insertions(+) > > > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
On Friday, June 27, 2014 7:12 PM, Ajay Kumar wrote:
>
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be set if we are using DP.
>
> Signed-off-by: Ajay Kumar
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> .../devicetree/bindings/video/samsung-fimd.txt |1 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
>
> include/video/samsung_fimd.h |4
> 3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> index 2dad41b..12f3d7a 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -41,6 +41,7 @@ Optional Properties:
> - samsung,power-domain: a phandle to FIMD power domain node.
> - samsung,invert-vden: video enable signal is inverted
> - samsung,invert-vclk: video clock signal is inverted
> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
> - display-timings: timing settings for FIMD, as described in document [1].
> Can be used in case timings cannot be provided otherwise
> or to override timings provided by the panel.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..aa74e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
> unsigned int has_shadowcon:1;
> unsigned int has_clksel:1;
> unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> .timing_base = 0x2,
> .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
> +};
> +
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DSI,
> + EXYNOS_FIMD_OUTPUT_DP,
> };
>
> struct fimd_win_data {
> @@ -125,6 +133,8 @@ struct fimd_context {
> struct exynos_drm_panel_info panel;
> struct fimd_driver_data *driver_data;
> struct exynos_drm_display *display;
> +
> + enum exynos_fimd_output_type exynos_fimd_output_type;
> };
>
> static const struct of_device_id fimd_driver_dt_match[] = {
> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> if (clkdiv > 1)
> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>
> + if (ctx->driver_data->has_dp_clkcon &&
> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
> writel(val, ctx->regs + VIDCON0);
> }
>
> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct fimd_context *ctx;
> struct resource *res;
> + u32 fimd_output_type;
> int ret = -EINVAL;
>
> ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
> @@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
> ctx->vidcon1 |= VIDCON1_INV_VDEN;
> if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
> ctx->vidcon1 |= VIDCON1_INV_VCLK;
> + if (!of_property_read_u32(dev->of_node, "samsung,output-type",
> + &fimd_output_type)) {
> + if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
> + (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
> + dev_err(dev, "invalid output type for FIMD\n");
> + else
> + ctx->exynos_fimd_output_type = fimd_output_type;
> + }
>
> ctx->bus_clk = devm_clk_get(dev, "fimd");
> if (IS_ERR(ctx->bus_clk)) {
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
> #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
> #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
> /* Notes on per-window bpp settings
> *
> * Value Win0 Win1 Win2 Win3 Win 4
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 0/7] drm/exynos: Support DP CLKCON register in FIMD driver
+ DT mailing list On 2014년 06월 27일 19:12, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > Changes since V2: > Add DT property to know the type of FIMD output interface > as per Inki's suggestion. > Add samsung,output-type DT property in FIMD node for all boards > supporting DP interface. > > Ajay Kumar (7): > [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver > [PATCH V3 2/7] ARM: dts: Add FIMD output property for snow > [PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit > [PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi > [PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250 > [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420 > [PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale > > .../devicetree/bindings/video/samsung-fimd.txt |1 + > arch/arm/boot/dts/exynos5250-arndale.dts |1 + > arch/arm/boot/dts/exynos5250-smdk5250.dts |1 + > arch/arm/boot/dts/exynos5250-snow.dts |1 + > arch/arm/boot/dts/exynos5420-peach-pit.dts |1 + > arch/arm/boot/dts/exynos5420-smdk5420.dts |1 + > arch/arm/boot/dts/exynos5800-peach-pi.dts |1 + > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23 > > include/video/samsung_fimd.h |4 > 9 files changed, 34 insertions(+) > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale
Set FIMD output type for arndale as DP.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5250-arndale.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..e803183 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -540,6 +540,7 @@
fimd: fimd@1440 {
status = "okay";
+ samsung,output-type = <2>;
display-timings {
native-mode = <&timing0>;
timing0: timing@0 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420
Set FIMD output type for smdk5420 as DP.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5420-smdk5420.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6052aa9..5f05a19 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -120,6 +120,7 @@
fimd@1440 {
status = "okay";
+ samsung,output-type = <2>;
display-timings {
native-mode = <&timing0>;
timing0: timing@0 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi
Set FIMD output type for peach_pi as DP.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5800-peach-pi.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3af207..21e2de2 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -205,6 +205,7 @@
&fimd {
status = "okay";
samsung,invert-vclk;
+ samsung,output-type = <2>;
};
&hsi2c_9 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250
Set FIMD output type for smdk5250 as DP.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5250-smdk5250.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a794a70..ed28efb 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -382,6 +382,7 @@
fimd@1440 {
status = "okay";
+ samsung,output-type = <2>;
display-timings {
native-mode = <&timing0>;
timing0: timing@0 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/7] ARM: dts: Add FIMD output property for snow
Set FIMD output type for snow as DP.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5250-snow.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 079fdf9..dc3ae9c 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -400,6 +400,7 @@
fimd@1440 {
status = "okay";
samsung,invert-vclk;
+ samsung,output-type = <2>;
};
dp-controller@145B {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit
Set FIMD output type for peach_pit as DP.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9..164f523 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -255,6 +255,7 @@
&fimd {
status = "okay";
samsung,invert-vclk;
+ samsung,output-type = <2>;
};
&dp {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be set if we are using DP.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/samsung-fimd.txt |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
include/video/samsung_fimd.h |4
3 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..12f3d7a 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -41,6 +41,7 @@ Optional Properties:
- samsung,power-domain: a phandle to FIMD power domain node.
- samsung,invert-vden: video enable signal is inverted
- samsung,invert-vclk: video clock signal is inverted
+- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
- display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..aa74e90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_dp_clkcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+ .has_dp_clkcon = 1,
+};
+
+enum exynos_fimd_output_type {
+ EXYNOS_FIMD_OUTPUT_DPI,
+ EXYNOS_FIMD_OUTPUT_DSI,
+ EXYNOS_FIMD_OUTPUT_DP,
};
struct fimd_win_data {
@@ -125,6 +133,8 @@ struct fimd_context {
struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
struct exynos_drm_display *display;
+
+ enum exynos_fimd_output_type exynos_fimd_output_type;
};
static const struct of_device_id fimd_driver_dt_match[] = {
@@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx->driver_data->has_dp_clkcon &&
+ ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
+ writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
+
writel(val, ctx->regs + VIDCON0);
}
@@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct fimd_context *ctx;
struct resource *res;
+ u32 fimd_output_type;
int ret = -EINVAL;
ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
@@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
ctx->vidcon1 |= VIDCON1_INV_VDEN;
if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
ctx->vidcon1 |= VIDCON1_INV_VCLK;
+ if (!of_property_read_u32(dev->of_node, "samsung,output-type",
+ &fimd_output_type)) {
+ if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
+ (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
+ dev_err(dev, "invalid output type for FIMD\n");
+ else
+ ctx->exynos_fimd_output_type = fimd_output_type;
+ }
ctx->bus_clk = devm_clk_get(dev, "fimd");
if (IS_ERR(ctx->bus_clk)) {
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
+/* Video clock enable for DP */
+#define DP_CLKCON 0x27C
+#define DP_CLK_ENABLE 0x2
+
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/7] drm/exynos: Support DP CLKCON register in FIMD driver
This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Changes since V2: Add DT property to know the type of FIMD output interface as per Inki's suggestion. Add samsung,output-type DT property in FIMD node for all boards supporting DP interface. Ajay Kumar (7): [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver [PATCH V3 2/7] ARM: dts: Add FIMD output property for snow [PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit [PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi [PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250 [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420 [PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale .../devicetree/bindings/video/samsung-fimd.txt |1 + arch/arm/boot/dts/exynos5250-arndale.dts |1 + arch/arm/boot/dts/exynos5250-smdk5250.dts |1 + arch/arm/boot/dts/exynos5250-snow.dts |1 + arch/arm/boot/dts/exynos5420-peach-pit.dts |1 + arch/arm/boot/dts/exynos5420-smdk5420.dts |1 + arch/arm/boot/dts/exynos5800-peach-pi.dts |1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23 include/video/samsung_fimd.h |4 9 files changed, 34 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/14] regulator: Add driver for Maxim 77802 PMIC regulators
Hello Lee, Thanks a lot for your feedback. On 06/27/2014 11:26 AM, Lee Jones wrote: > On Thu, 26 Jun 2014, Javier Martinez Canillas wrote: >> The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout >> (LDO) regulators. This patch adds support for all these regulators >> found on the MAX77802 PMIC and is based on a driver added by Simon >> Glass to the Chrome OS kernel 3.8 tree. >> >> Signed-off-by: Javier Martinez Canillas >> Tested-by: Naveen Krishna Chatradhi >> --- >> >> Changes since v4: None >> >> Changes since v3: >> - Set the supply_name for regulators to lookup their parent supply node. >>Suggested by Mark Brown. >> - Change Exyno5 for Exynos5420/Exynos5800 in regulator driver Kconfig. >>Suggested by Doug Anderson. >> >> Changes since v2: >> - Use dev_warn() instead pr_warn(). Suggested by Mark Brown. >> - Add a generic function to regmap core to copy registers instead of >>having a driver-specific function. Suggested by Mark Brown. >> - Remove unnecessary probe debug log. Suggested by Mark Brown. >> - Set struct regulator_config dev field to MFD instead of the platform dev. >>Suggested by Mark Brown. >> - Read the regulators operational mode from the hardware registers instead >>of setting to normal as default on probe. Suggested by Mark Brown. >> - Remove unnecessary cross-subsystem dependencies. Suggested by Lee Jones. >> >> Changes since v1: >> - Remove unneeded check if num_regulators != MAX77802_MAX_REGULATORS. >> - Fix .set_suspend_mode handler comment and split regulators ops for >>regulators that behave differently. Suggested by Mark Brown. >> - Use module_platform_driver() instead of having init/exit functions. >>Suggested by Mark Brown. >> - Use the new descriptor-based GPIO interface instead of the deprecated >>integer based GPIO one. Suggested by Mark Brown. >> - Look for "regulators" child node instead of "voltage-regulators" to be >>consistent with other PMIC drivers. Suggested by Mark Brown. >> >> drivers/mfd/max77802.c | 8 +- >> drivers/regulator/Kconfig| 9 + >> drivers/regulator/Makefile | 1 + >> drivers/regulator/max77802.c | 694 >> +++ >> include/linux/mfd/max77802-private.h | 3 - >> 5 files changed, 711 insertions(+), 4 deletions(-) >> create mode 100644 drivers/regulator/max77802.c >> >> diff --git a/drivers/mfd/max77802.c b/drivers/mfd/max77802.c >> index 3d477fb..79d36b6 100644 >> --- a/drivers/mfd/max77802.c >> +++ b/drivers/mfd/max77802.c >> @@ -228,7 +228,7 @@ static int max77802_i2c_probe(struct i2c_client *i2c, >> >> max77802 = devm_kzalloc(&i2c->dev, sizeof(struct max77802_dev), >> GFP_KERNEL); >> -if (max77802 == NULL) >> +if (!max77802) >> return -ENOMEM; >> >> i2c_set_clientdata(i2c, max77802); >> @@ -315,6 +315,12 @@ static int max77802_suspend(struct device *dev) >> if (device_may_wakeup(dev)) >> enable_irq_wake(max77802->irq); >> >> +/* >> + * The IRQ must be disabled during suspend since due wakeup >> + * ordering issues it may be possible that the I2C controller >> + * is still suspended when the interrupt happens so the IRQ >> + * handler will fail to read the I2C bus. >> + */ > > Please re-word this, the English is a little off. > Ok, I found that drivers/mfd/max14577.c has a similar comment so I'll just reuse that one since explains it way better. >> disable_irq(max77802->irq); >> >> return 0; > > Please separate the MFD changes out. There is no need for them to be > munged in with regulator changes. > Yes, when preparing v5 I squashed the mfd driver changes into the patch adding the regulator driver by mistake instead with the one adding the mfd driver. Sorry about that... I'll wait for your complete review so I can fix all the issues you find and post a v6. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
On Fri, Jun 27, 2014 at 02:09:58AM -0700, Laura Abbott wrote: > On 6/26/2014 8:06 PM, Tushar Behera wrote: >> arm_add_memory is getting called before this is being set, resulting in >> none of the memory banks getting added[1]. >> >> setup_machine_fdt -> early_init_dt_scan -> early_init_dt_scan_memory >> >> Would it make sense to re-introduce the config option ARM_NR_BANKS and >> replace max_cnt with NR_BANKS? >> >> [1] http://pastebin.com/MawYD7kb >> > > I was hoping to avoid re-introducing the config option but that may be > the case if we can't make the machine_info work. I'll take a better > look tomorrow. The problem with the config option is that it's not single zImage friendly. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system
Hello Lee, On 06/27/2014 11:21 AM, Lee Jones wrote: > On Thu, 26 Jun 2014, Javier Martinez Canillas wrote: > >> From: Doug Anderson >> >> The max77686 includes an RTC that keeps power during suspend. It's >> convenient to be able to use it as a wakeup source. >> >> NOTE: due to wakeup ordering problems this patch alone doesn't work so >> well on exynos5250-snow. You also need something that brings the i2c >> bus up before the max77686 wakeup runs. >> >> Signed-off-by: Doug Anderson >> Reviewed-by: Javier Martinez Canillas >> Reviewed-by: Krzysztof Kozlowski >> --- >> >> Changes since v4: None >> >> Changes since v3: >> - Keep the note that this patch needs another change due wakeup >>ordering problems. >> >> drivers/rtc/rtc-max77686.c | 28 >> 1 file changed, 28 insertions(+) > > This patch doesn't actually touch the MFD subsystem directly. Can you > change the $SUBJECT line accordingly please? > You're right, I'll change the $subject. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/14] regulator: Add driver for Maxim 77802 PMIC regulators
On Thu, 26 Jun 2014, Javier Martinez Canillas wrote: > The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout > (LDO) regulators. This patch adds support for all these regulators > found on the MAX77802 PMIC and is based on a driver added by Simon > Glass to the Chrome OS kernel 3.8 tree. > > Signed-off-by: Javier Martinez Canillas > Tested-by: Naveen Krishna Chatradhi > --- > > Changes since v4: None > > Changes since v3: > - Set the supply_name for regulators to lookup their parent supply node. >Suggested by Mark Brown. > - Change Exyno5 for Exynos5420/Exynos5800 in regulator driver Kconfig. >Suggested by Doug Anderson. > > Changes since v2: > - Use dev_warn() instead pr_warn(). Suggested by Mark Brown. > - Add a generic function to regmap core to copy registers instead of >having a driver-specific function. Suggested by Mark Brown. > - Remove unnecessary probe debug log. Suggested by Mark Brown. > - Set struct regulator_config dev field to MFD instead of the platform dev. >Suggested by Mark Brown. > - Read the regulators operational mode from the hardware registers instead >of setting to normal as default on probe. Suggested by Mark Brown. > - Remove unnecessary cross-subsystem dependencies. Suggested by Lee Jones. > > Changes since v1: > - Remove unneeded check if num_regulators != MAX77802_MAX_REGULATORS. > - Fix .set_suspend_mode handler comment and split regulators ops for >regulators that behave differently. Suggested by Mark Brown. > - Use module_platform_driver() instead of having init/exit functions. >Suggested by Mark Brown. > - Use the new descriptor-based GPIO interface instead of the deprecated >integer based GPIO one. Suggested by Mark Brown. > - Look for "regulators" child node instead of "voltage-regulators" to be >consistent with other PMIC drivers. Suggested by Mark Brown. > > drivers/mfd/max77802.c | 8 +- > drivers/regulator/Kconfig| 9 + > drivers/regulator/Makefile | 1 + > drivers/regulator/max77802.c | 694 > +++ > include/linux/mfd/max77802-private.h | 3 - > 5 files changed, 711 insertions(+), 4 deletions(-) > create mode 100644 drivers/regulator/max77802.c > > diff --git a/drivers/mfd/max77802.c b/drivers/mfd/max77802.c > index 3d477fb..79d36b6 100644 > --- a/drivers/mfd/max77802.c > +++ b/drivers/mfd/max77802.c > @@ -228,7 +228,7 @@ static int max77802_i2c_probe(struct i2c_client *i2c, > > max77802 = devm_kzalloc(&i2c->dev, sizeof(struct max77802_dev), > GFP_KERNEL); > - if (max77802 == NULL) > + if (!max77802) > return -ENOMEM; > > i2c_set_clientdata(i2c, max77802); > @@ -315,6 +315,12 @@ static int max77802_suspend(struct device *dev) > if (device_may_wakeup(dev)) > enable_irq_wake(max77802->irq); > > + /* > + * The IRQ must be disabled during suspend since due wakeup > + * ordering issues it may be possible that the I2C controller > + * is still suspended when the interrupt happens so the IRQ > + * handler will fail to read the I2C bus. > + */ Please re-word this, the English is a little off. > disable_irq(max77802->irq); > > return 0; Please separate the MFD changes out. There is no need for them to be munged in with regulator changes. [...] -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system
On Thu, 26 Jun 2014, Javier Martinez Canillas wrote: > From: Doug Anderson > > The max77686 includes an RTC that keeps power during suspend. It's > convenient to be able to use it as a wakeup source. > > NOTE: due to wakeup ordering problems this patch alone doesn't work so > well on exynos5250-snow. You also need something that brings the i2c > bus up before the max77686 wakeup runs. > > Signed-off-by: Doug Anderson > Reviewed-by: Javier Martinez Canillas > Reviewed-by: Krzysztof Kozlowski > --- > > Changes since v4: None > > Changes since v3: > - Keep the note that this patch needs another change due wakeup >ordering problems. > > drivers/rtc/rtc-max77686.c | 28 > 1 file changed, 28 insertions(+) This patch doesn't actually touch the MFD subsystem directly. Can you change the $SUBJECT line accordingly please? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
On 6/26/2014 8:06 PM, Tushar Behera wrote:
On 06/27/2014 01:12 AM, Laura Abbott wrote:
+static unsigned int bank_cnt;
+static unsigned int max_cnt;
+
int __init arm_add_memory(u64 start, u64 size)
{
u64 aligned_start;
/*
+* Some buggy bootloaders rely on the old meminfo behavior of not adding
+* more than n banks since anything past that may contain invalid data.
+*/
+ if (bank_cnt >= max_cnt) {
+ pr_crit("Max banks too low, ignoring memory at 0x%08llx\n",
+ (long long)start);
+ return -EINVAL;
+ }
+
+ bank_cnt++;
+
+ /*
* Ensure that start/size are aligned to a page boundary.
* Size is appropriately rounded down, start is rounded up.
*/
@@ -879,6 +894,7 @@ void __init setup_arch(char **cmdline_p)
mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
machine_desc = mdesc;
machine_name = mdesc->name;
+ max_cnt = mdesc->bank_limit;
arm_add_memory is getting called before this is being set, resulting in
none of the memory banks getting added[1].
setup_machine_fdt -> early_init_dt_scan -> early_init_dt_scan_memory
Would it make sense to re-introduce the config option ARM_NR_BANKS and
replace max_cnt with NR_BANKS?
[1] http://pastebin.com/MawYD7kb
I was hoping to avoid re-introducing the config option but that may be
the case if we can't make the machine_info work. I'll take a better
look tomorrow.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock
Hello Andreas, On 06/27/2014 10:26 AM, Andreas Färber wrote: > Hi Javier, > > Am 27.06.2014 09:53, schrieb Javier Martinez Canillas: >> Hello Andreas, >> >> On 06/27/2014 09:48 AM, Andreas Färber wrote: >>> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas: This patch adds a dt-binding include for Maxim 77686 PMIC clock IDs that can be to be shared between the >>> >>> "can be shared"? >>> >> >> As it should be quite clear right now I'm not a native English speaker. > > Guessed so, me neither. But since it's v5 already and no native speaker > pointed it out, I took the liberty to do so while verifying that the > LD02 typo didn't propagate into your bindings documentation (it didn't). > >> I meant >> that the header file can be included by both Device Tree source files and the >> max77802 driver. > > AFAIU "clock IDs to be shared" and "clock IDs that can be shared" would > both be valid, but above a verb is missing (e.g., "can be used to"). > > Thanks for your upstreaming efforts, and don't let me discourage you. > No discourage at all, your feedback is highly appreciated and sorry that I didn't catch all these typos when working on the DT documentation. > Best regards, > > Andreas > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 08/14] mfd: max77802: Add DT binding documentation
Hello Andreas,
Thanks a lot for your feedback.
On 06/27/2014 10:06 AM, Andreas Färber wrote:
> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
>> Add Device Tree binding documentation for Maxim 77802 PMIC.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> Changes since v4: None
>>
>> Changes since v3: None
>>
>> Changes since v2:
>> - Explain better the Dynamic Voltage Scaling (DVS) support in some Buck
>>regulators and the max77802,pmic-buck-{dvs,selb}-gpios properties.
>>Suggested by Mark Brown.
>>
>> Documentation/devicetree/bindings/mfd/max77802.txt | 97
>> ++
>> 1 file changed, 97 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
>> b/Documentation/devicetree/bindings/mfd/max77802.txt
>> new file mode 100644
>> index 000..f3b67c5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
>> @@ -0,0 +1,97 @@
>> +Maxim MAX77802 multi-function device
>> +
>> +MAX77802 is a Mulitifunction device with PMIC, RTC and Charger on chip. It
>> is
>
> "Multifunction"?
>
Yes, another typo. I'll fix it on the next series as well.
>> +interfaced to host controller using i2c interface. PMIC, Charger and RTC
>> +submodules are addressed using same i2c slave address.
>> +
>> +Buck regulators 1, 2, 3, 4 and 6 include Dynamic Voltage Scaling (DVS) that
>> +allows each output voltage to change dynamically. Each Buck output voltage
>> +is selected using a set of external inputs: DVS1-3 and SELB1, 2, 3 and 6.
>> +
>> +There are 8 DVS registers that can be used to configure the output voltage
>> +for each Buck regulator and which one is active is controled by DVSx lines.
>> +
>> +SELBx lines are used to control if individual Buck lines are ON or OFF.
>> +
>> +This document describes the binding for mfd device and PMIC submodule.
>> +
>> +Binding for the built-in 32k clock generator block is defined separately
>> +in bindings/clk/maxim,max77802.txt file.
>> +
>> +Required properties:
>> +- compatible : Must be "maxim,max77802";
>> +- reg : Specifies the i2c slave address of PMIC block.
>> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Optional properties:
>> +- max77802,pmic-buck-default-dvs-idx: We'll always write this DVS index in
>> the
>> + PMIC for Bucks with DVS.
>> + NOTE: at the moment these bindings don't include enough details for actual
>> + GPIO-DVS--this just lets you choose which single slot to use.
>> +
>> +- max77802,pmic-buck-dvs-gpios: A GPIO array where each GPIO is connected
>> to a
>> + DVS line. We'll try to set these GPIOs to match pmic-buck-default-dvs-idx
>> at
>> + probe time if they are defined. If some or all of these GPIOs are not
>> defined
>> + it's assumed that the board has any missing GPIOs hardwired to match
>> + pmic-buck-default-dvs-idx.
>> +
>> +- max77802,pmic-buck-selb-gpios: A GPIO array where each GPIO is connected
>> to a
>> + SELBx line. Should be five values: 1, 2, 3, 4, 6. It is strongly
>> suggested to
>> + include these GPIOs if there's any chance that changing DVS GPIOs one
>> line at
>> + a time might glitch your DVS values.
>> +
>> +Optional node:
>> +- regulators : The regulators of max77802 have to be instantiated
>> + under subnode named "regulators" using the following format.
>> +
>> +regulator_name {
>
> The convention, I was told, would be regulator-name as node name.
>
Ok, I'll change this to regulator-name. It is a symbolic name to refer to the
regulator node name anyways since now that the regulator-compatible property is
deprecated, the regulator node name is used for matching. So the list of valid
regulator node names is properly defined below:
>> +
>> + The regulator node name should be initialized with a string
>> +to get matched with their hardware counterparts as follow:
>> +
>> +-LDOn : for LDOs, where n can lie in range 1 to 35.
>> +example: LDO1, LDO2, LDO35.
>> +-BUCKn : for BUCKs, where n can lie in range 1 to 10.
>> +example: BUCK1, BUCK5, BUCK10.
>> +Example:
>> +
>> +max77802@09 {
>> +compatible = "maxim,max77802";
>> +interrupt-parent = <&wakeup_eint>;
>> +interrupts = <26 0>;
>> +reg = <0x09>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +max77802,pmic-buck-default-dvs-idx = <1>;
>> +max77802,pmic-buck-dvs-gpios = <&gpy7 6 0>,
>> + <&gpj4 2 0>,
>> + <&gpj4 3 0>;
>> +max77802,pmic-buck-selb-gpios = <&gph0 2 0>,
>> +<&gph0 3 0>,
>> +<&gph0 4 0>,
>> +
Re: [PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver
Hi Inki,
Thanks for the review.
On Fri, Jun 27, 2014 at 1:04 PM, Inki Dae wrote:
> On 2014년 06월 26일 23:36, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be used if we are using DP.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> Changes since V1:
>> - Remove usage of driver_data to configure DP CLKCON register
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 2 ++
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 8
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
>> include/video/samsung_fimd.h | 4
>> 4 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 2e77a15..d8868f3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct
>> device *master, void *data)
>>
>> platform_set_drvdata(pdev, &exynos_dp_display);
>>
>> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
>> +
>> return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
>> }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 36535f3..1089744 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
>> EXYNOS_DISPLAY_TYPE_VIDI,
>> };
>>
>> +enum exynos_fimd_output_type {
>> + EXYNOS_FIMD_OUTPUT_MIPI,
>> + EXYNOS_FIMD_OUTPUT_DPI,
>> + EXYNOS_FIMD_OUTPUT_DP,
>> +};
>> +
>> /*
>> * Exynos drm common overlay structure.
>> *
>> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
>> extern struct platform_driver rotator_driver;
>> extern struct platform_driver gsc_driver;
>> extern struct platform_driver ipp_driver;
>> +
>> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
>> #endif
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index bb45ab2..a46a9c4 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
>> .has_shadowcon = 1,
>> };
>>
>> +enum exynos_fimd_output_type exynos_fimd_output_type;
>> +
>> struct fimd_win_data {
>> unsigned intoffset_x;
>> unsigned intoffset_y;
>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>> if (clkdiv > 1)
>> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>
>> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>
>
> You are passing output type directly from dp driver to fimd driver using
> extern variable. This is really not good. Is that really only way for it?
>
> One is,
> it's to add a dt property in fimd node and use it; ex.
> samsung,output_type. Whether fimd output should be DPI, DSI, or eDP
> would be dependent on Machine.
>
> Other is,
> crtc driver is to get output type though encoder callback. At this
> moment, crtc driver already knows encoder/connector driver. So I think
> you can use a callback of encoder to get output type like below,
>
> exynos_display_ops {
> ...
> ...get_output(struct drm_crtc *crtc);
> };
>
> at exynos_drm_encoder.c,
> ... exynos_drm_get_output_type(struct drm_crtc *crtc)
> {
> ...
> return display_ops->get_output(...);
> }
>
> at fimd_commit function,
> ...
> ctx->output_type = exynos_drm_get_output_type(mgr->crtc);
>
>
> I think first way is more simple and reasonable.
>
> One more thing, does FIMD ip of Exynos4 series have DP_CLKCON register?
> No, they have no any DP_CLKCON register so you would need to consider
> other SoC without DP_CLKCON. For this, a proper volunteer would be
> fimd_driver_data.
Right, I should also consider putting DP CLKCON register inside driver_data.
And, I will use the DT property you mentioned.
Will send a patchset ASAP.
Regards,
Ajay Kumar
> Thanks,
> Inki Dae
>
>
>> +
>> writel(val, ctx->regs + VIDCON0);
>> }
>>
>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>> index b039320..d8f4b0b 100644
>> --- a/include/video/samsung_fimd.h
>> +++ b/include/video/samsung_fimd.h
>> @@ -435,6 +435,10 @@
>> #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>> #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>>
>> +/* Video clock enable for DP */
>> +#define DP_CLKCON0x27C
>> +#define DP_CLK_ENABLE0x2
>> +
>> /* Notes on per-window bpp settings
>> *
>> * Value Win0 Win1 Win2 Win3 Win 4
>>
>
--
To unsubscribe from this list: send the lin
Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock
Hi Javier, Am 27.06.2014 09:53, schrieb Javier Martinez Canillas: > Hello Andreas, > > On 06/27/2014 09:48 AM, Andreas Färber wrote: >> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas: >>> This patch adds a dt-binding include for Maxim 77686 >>> PMIC clock IDs that can be to be shared between the >> >> "can be shared"? >> > > As it should be quite clear right now I'm not a native English speaker. Guessed so, me neither. But since it's v5 already and no native speaker pointed it out, I took the liberty to do so while verifying that the LD02 typo didn't propagate into your bindings documentation (it didn't). > I meant > that the header file can be included by both Device Tree source files and the > max77802 driver. AFAIU "clock IDs to be shared" and "clock IDs that can be shared" would both be valid, but above a verb is missing (e.g., "can be used to"). Thanks for your upstreaming efforts, and don't let me discourage you. Best regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 08/14] mfd: max77802: Add DT binding documentation
Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
> Add Device Tree binding documentation for Maxim 77802 PMIC.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v4: None
>
> Changes since v3: None
>
> Changes since v2:
> - Explain better the Dynamic Voltage Scaling (DVS) support in some Buck
>regulators and the max77802,pmic-buck-{dvs,selb}-gpios properties.
>Suggested by Mark Brown.
>
> Documentation/devicetree/bindings/mfd/max77802.txt | 97
> ++
> 1 file changed, 97 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
> b/Documentation/devicetree/bindings/mfd/max77802.txt
> new file mode 100644
> index 000..f3b67c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
> @@ -0,0 +1,97 @@
> +Maxim MAX77802 multi-function device
> +
> +MAX77802 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is
"Multifunction"?
> +interfaced to host controller using i2c interface. PMIC, Charger and RTC
> +submodules are addressed using same i2c slave address.
> +
> +Buck regulators 1, 2, 3, 4 and 6 include Dynamic Voltage Scaling (DVS) that
> +allows each output voltage to change dynamically. Each Buck output voltage
> +is selected using a set of external inputs: DVS1-3 and SELB1, 2, 3 and 6.
> +
> +There are 8 DVS registers that can be used to configure the output voltage
> +for each Buck regulator and which one is active is controled by DVSx lines.
> +
> +SELBx lines are used to control if individual Buck lines are ON or OFF.
> +
> +This document describes the binding for mfd device and PMIC submodule.
> +
> +Binding for the built-in 32k clock generator block is defined separately
> +in bindings/clk/maxim,max77802.txt file.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77802";
> +- reg : Specifies the i2c slave address of PMIC block.
> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
> +- interrupt-parent : The parent interrupt controller.
> +
> +Optional properties:
> +- max77802,pmic-buck-default-dvs-idx: We'll always write this DVS index in
> the
> + PMIC for Bucks with DVS.
> + NOTE: at the moment these bindings don't include enough details for actual
> + GPIO-DVS--this just lets you choose which single slot to use.
> +
> +- max77802,pmic-buck-dvs-gpios: A GPIO array where each GPIO is connected to
> a
> + DVS line. We'll try to set these GPIOs to match pmic-buck-default-dvs-idx
> at
> + probe time if they are defined. If some or all of these GPIOs are not
> defined
> + it's assumed that the board has any missing GPIOs hardwired to match
> + pmic-buck-default-dvs-idx.
> +
> +- max77802,pmic-buck-selb-gpios: A GPIO array where each GPIO is connected
> to a
> + SELBx line. Should be five values: 1, 2, 3, 4, 6. It is strongly suggested
> to
> + include these GPIOs if there's any chance that changing DVS GPIOs one line
> at
> + a time might glitch your DVS values.
> +
> +Optional node:
> +- regulators : The regulators of max77802 have to be instantiated
> + under subnode named "regulators" using the following format.
> +
> + regulator_name {
The convention, I was told, would be regulator-name as node name.
> + standard regulator constraints
> + };
> + refer Documentation/devicetree/bindings/regulator/regulator.txt
> +
> + The regulator node name should be initialized with a string
> +to get matched with their hardware counterparts as follow:
> +
> + -LDOn : for LDOs, where n can lie in range 1 to 35.
> + example: LDO1, LDO2, LDO35.
> + -BUCKn : for BUCKs, where n can lie in range 1 to 10.
> + example: BUCK1, BUCK5, BUCK10.
> +Example:
> +
> + max77802@09 {
> + compatible = "maxim,max77802";
> + interrupt-parent = <&wakeup_eint>;
> + interrupts = <26 0>;
> + reg = <0x09>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + max77802,pmic-buck-default-dvs-idx = <1>;
> + max77802,pmic-buck-dvs-gpios = <&gpy7 6 0>,
> +<&gpj4 2 0>,
> +<&gpj4 3 0>;
> + max77802,pmic-buck-selb-gpios = <&gph0 2 0>,
> + <&gph0 3 0>,
> + <&gph0 4 0>,
> + <&gph0 5 0>,
> + <&gph0 6 0>;
> +
> + regulators {
> + ldo11_reg: LDO11 {
> + regulator-compatible = "LDO11";
> + regulator-name = "vdd_ldo11";
> + regulator-min-microvolt = <190>;
> + regulator-max-microvolt = <190>
Re: [PATCH v5 12/14] clk: max77802: Add DT binding documentation
Hello Andres, Thanks a lot for your feedback. On 06/27/2014 09:52 AM, Andreas Färber wrote: > Am 26.06.2014 20:15, schrieb Javier Martinez Canillas: >> Add Device Tree binding documentation for the clocks >> outputs in the Maxim 77802 Power Management IC. >> >> Signed-off-by: Javier Martinez Canillas >> --- >> >> Changes since v4: None >> >> Changes since v3: >> - Don't use the same clock driver name in clock-names since it's a consumer >>concept and most probably will be different. Suggested by Doug Anderson. >> >> Changes since v2: >> - Split the DT binding documentation in a separate patch. >> >> .../devicetree/bindings/clock/maxim,max77802.txt | 42 >> ++ >> 1 file changed, 42 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/clock/maxim,max77802.txt >> >> diff --git a/Documentation/devicetree/bindings/clock/maxim,max77802.txt >> b/Documentation/devicetree/bindings/clock/maxim,max77802.txt >> new file mode 100644 >> index 000..26bc4f7 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/clock/maxim,max77802.txt >> @@ -0,0 +1,42 @@ >> +Binding for Maxim MAX77802 32k clock generator block >> + >> +This is a part of device tree bindings of MAX77802 multi-function device. >> +More information can be found in bindings/mfd/max77802.txt file. >> + >> +The MAX77802 contains two 32.768khz clock outputs that can be controlled >> +(gated/ungated) over I2C. >> + >> +Following properties should be presend in main device node of the MFD chip. > > "present" > Right, it's a typo. I'll wait for further feedback and will fix both issues you pointed out in the next version of the series. > Regards, > Andreas > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock
Hello Andreas, On 06/27/2014 09:48 AM, Andreas Färber wrote: > Am 26.06.2014 20:15, schrieb Javier Martinez Canillas: >> This patch adds a dt-binding include for Maxim 77686 >> PMIC clock IDs that can be to be shared between the > > "can be shared"? > As it should be quite clear right now I'm not a native English speaker. I meant that the header file can be included by both Device Tree source files and the max77802 driver. > Regards, > Andreas > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 12/14] clk: max77802: Add DT binding documentation
Am 26.06.2014 20:15, schrieb Javier Martinez Canillas: > Add Device Tree binding documentation for the clocks > outputs in the Maxim 77802 Power Management IC. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v4: None > > Changes since v3: > - Don't use the same clock driver name in clock-names since it's a consumer >concept and most probably will be different. Suggested by Doug Anderson. > > Changes since v2: > - Split the DT binding documentation in a separate patch. > > .../devicetree/bindings/clock/maxim,max77802.txt | 42 > ++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/maxim,max77802.txt > > diff --git a/Documentation/devicetree/bindings/clock/maxim,max77802.txt > b/Documentation/devicetree/bindings/clock/maxim,max77802.txt > new file mode 100644 > index 000..26bc4f7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/maxim,max77802.txt > @@ -0,0 +1,42 @@ > +Binding for Maxim MAX77802 32k clock generator block > + > +This is a part of device tree bindings of MAX77802 multi-function device. > +More information can be found in bindings/mfd/max77802.txt file. > + > +The MAX77802 contains two 32.768khz clock outputs that can be controlled > +(gated/ungated) over I2C. > + > +Following properties should be presend in main device node of the MFD chip. "present" Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock
Am 26.06.2014 20:15, schrieb Javier Martinez Canillas: > This patch adds a dt-binding include for Maxim 77686 > PMIC clock IDs that can be to be shared between the "can be shared"? Regards, Andreas > clk-max77686 clock driver and DeviceTree source files. > > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Krzysztof Kozlowski > --- > > Changes since v4: None > > Changes since v3: None -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver
Am 26.06.2014 16:36, schrieb Ajay Kumar:
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
>
> Signed-off-by: Ajay Kumar
> ---
> Changes since V1:
> - Remove usage of driver_data to configure DP CLKCON register
> drivers/gpu/drm/exynos/exynos_dp_core.c | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 8
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
> include/video/samsung_fimd.h | 4
> 4 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 2e77a15..d8868f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
>
> platform_set_drvdata(pdev, &exynos_dp_display);
>
> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
> +
> return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..1089744 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
> EXYNOS_DISPLAY_TYPE_VIDI,
> };
>
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_MIPI,
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DP,
> +};
> +
> /*
> * Exynos drm common overlay structure.
> *
> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
> extern struct platform_driver rotator_driver;
> extern struct platform_driver gsc_driver;
> extern struct platform_driver ipp_driver;
> +
> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..a46a9c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
> .has_shadowcon = 1,
> };
>
> +enum exynos_fimd_output_type exynos_fimd_output_type;
This is a non-static variable - doesn't that mean it's only ever
initialized to DP above and uninitialized in C99 otherwise? Unless I'm
missing something, the if below may trigger at random.
Regards,
Andreas
> +
> struct fimd_win_data {
> unsigned intoffset_x;
> unsigned intoffset_y;
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> if (clkdiv > 1)
> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>
> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
> writel(val, ctx->regs + VIDCON0);
> }
>
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
> #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
> #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
> /* Notes on per-window bpp settings
> *
> * Value Win0 Win1 Win2 Win3 Win 4
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback
On Wed, Jun 25, 2014 at 3:37 PM, Tomasz Figa wrote: > For certain platforms (e.g. Exynos) it is necessary to read back some > values from registers before they can be written (i.e. SMC calls that > set multiple registers per call), so base address of L2C controller is > needed for .write_sec operation. This patch adds base argument to > .write_sec callback so that its implementation can also access registers > directly. > > Signed-off-by: Tomasz Figa > arch/arm/mach-ux500/cache-l2x0.c | 3 ++- In our case just changing the signature of the function I see so: Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver
On 2014년 06월 26일 23:36, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
>
> Signed-off-by: Ajay Kumar
> ---
> Changes since V1:
> - Remove usage of driver_data to configure DP CLKCON register
> drivers/gpu/drm/exynos/exynos_dp_core.c | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 8
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
> include/video/samsung_fimd.h | 4
> 4 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 2e77a15..d8868f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
>
> platform_set_drvdata(pdev, &exynos_dp_display);
>
> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
> +
> return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..1089744 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
> EXYNOS_DISPLAY_TYPE_VIDI,
> };
>
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_MIPI,
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DP,
> +};
> +
> /*
> * Exynos drm common overlay structure.
> *
> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
> extern struct platform_driver rotator_driver;
> extern struct platform_driver gsc_driver;
> extern struct platform_driver ipp_driver;
> +
> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..a46a9c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
> .has_shadowcon = 1,
> };
>
> +enum exynos_fimd_output_type exynos_fimd_output_type;
> +
> struct fimd_win_data {
> unsigned intoffset_x;
> unsigned intoffset_y;
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> if (clkdiv > 1)
> val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>
> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
You are passing output type directly from dp driver to fimd driver using
extern variable. This is really not good. Is that really only way for it?
One is,
it's to add a dt property in fimd node and use it; ex.
samsung,output_type. Whether fimd output should be DPI, DSI, or eDP
would be dependent on Machine.
Other is,
crtc driver is to get output type though encoder callback. At this
moment, crtc driver already knows encoder/connector driver. So I think
you can use a callback of encoder to get output type like below,
exynos_display_ops {
...
...get_output(struct drm_crtc *crtc);
};
at exynos_drm_encoder.c,
... exynos_drm_get_output_type(struct drm_crtc *crtc)
{
...
return display_ops->get_output(...);
}
at fimd_commit function,
...
ctx->output_type = exynos_drm_get_output_type(mgr->crtc);
I think first way is more simple and reasonable.
One more thing, does FIMD ip of Exynos4 series have DP_CLKCON register?
No, they have no any DP_CLKCON register so you would need to consider
other SoC without DP_CLKCON. For this, a proper volunteer would be
fimd_driver_data.
Thanks,
Inki Dae
> +
> writel(val, ctx->regs + VIDCON0);
> }
>
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
> #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
> #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
> /* Notes on per-window bpp settings
> *
> * Value Win0 Win1 Win2 Win3 Win 4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
