* [PATCH 2/2] powerpc, video: add SM501 support for charon board.
From: Heiko Schocher @ 2010-12-04 8:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-fbdev, Heiko Schocher
In-Reply-To: <1291451028-22532-1-git-send-email-hs@denx.de>
Signed-off-by: Heiko Schocher <hs@denx.de>
cc: linux-fbdev@vger.kernel.org
---
based against 2.6.37-rc4
./scripts/checkpatch.pl 0004-powerpc-video-add-SM501-support-for-charon-board.patch lems and is ready for
total: 0 errors, 0 warnings, 249 lines checked
0004-powerpc-video-add-SM501-support-for-charon-board.patch has no obvious style problems and is ready for submission.
arch/powerpc/boot/dts/charon.dts | 9 ++
arch/powerpc/configs/52xx/charon_defconfig | 176 +++++++++++++++++++++++++++-
2 files changed, 179 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts
index 768f0cc..b2353b3 100644
--- a/arch/powerpc/boot/dts/charon.dts
+++ b/arch/powerpc/boot/dts/charon.dts
@@ -186,6 +186,7 @@
#address-cells = <2>;
#size-cells = <1>;
ranges = < 0 0 0xfc000000 0x02000000
+ 1 0 0xe0000000 0x04000000 // CS1 range, SM501
3 0 0xe8000000 0x00080000>;
flash@0,0 {
@@ -197,6 +198,14 @@
#address-cells = <1>;
};
+ display@1,0 {
+ compatible = "smi,sm501";
+ reg = <1 0x00000000 0x00800000
+ 1 0x03e00000 0x00200000>;
+ mode = "640x480-32@60";
+ interrupts = <1 1 3>;
+ };
+
mram0@3,0 {
compatible = "mtd-ram";
reg = <3 0x00000 0x80000>;
diff --git a/arch/powerpc/configs/52xx/charon_defconfig b/arch/powerpc/configs/52xx/charon_defconfig
index edf3d40..05a46cf 100644
--- a/arch/powerpc/configs/52xx/charon_defconfig
+++ b/arch/powerpc/configs/52xx/charon_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux/powerpc 2.6.37-rc4 Kernel Configuration
-# Tue Nov 30 12:24:32 2010
+# Tue Nov 30 12:32:58 2010
#
# CONFIG_PPC64 is not set
@@ -719,18 +719,78 @@ CONFIG_WLAN=y
#
# Input device support
#
-# CONFIG_INPUT is not set
+CONFIG_INPUT=y
+# CONFIG_INPUT_FF_MEMLESS is not set
+# CONFIG_INPUT_POLLDEV is not set
+# CONFIG_INPUT_SPARSEKMAP is not set
+
+#
+# Userland interfaces
+#
+CONFIG_INPUT_MOUSEDEV=y
+CONFIG_INPUT_MOUSEDEV_PSAUX=y
+CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
+CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_EVDEV is not set
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input Device Drivers
+#
+CONFIG_INPUT_KEYBOARD=y
+# CONFIG_KEYBOARD_ADP5588 is not set
+CONFIG_KEYBOARD_ATKBD=y
+# CONFIG_KEYBOARD_QT2160 is not set
+# CONFIG_KEYBOARD_LKKBD is not set
+# CONFIG_KEYBOARD_TCA6416 is not set
+# CONFIG_KEYBOARD_MAX7359 is not set
+# CONFIG_KEYBOARD_MCS is not set
+# CONFIG_KEYBOARD_NEWTON is not set
+# CONFIG_KEYBOARD_OPENCORES is not set
+# CONFIG_KEYBOARD_STOWAWAY is not set
+# CONFIG_KEYBOARD_SUNKBD is not set
+# CONFIG_KEYBOARD_XTKBD is not set
+CONFIG_INPUT_MOUSE=y
+CONFIG_MOUSE_PS2=y
+CONFIG_MOUSE_PS2_ALPS=y
+CONFIG_MOUSE_PS2_LOGIPS2PP=y
+CONFIG_MOUSE_PS2_SYNAPTICS=y
+CONFIG_MOUSE_PS2_TRACKPOINT=y
+# CONFIG_MOUSE_PS2_ELANTECH is not set
+# CONFIG_MOUSE_PS2_SENTELIC is not set
+# CONFIG_MOUSE_PS2_TOUCHKIT is not set
+# CONFIG_MOUSE_SERIAL is not set
+# CONFIG_MOUSE_APPLETOUCH is not set
+# CONFIG_MOUSE_BCM5974 is not set
+# CONFIG_MOUSE_VSXXXAA is not set
+# CONFIG_MOUSE_SYNAPTICS_I2C is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TABLET is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
-# CONFIG_SERIO is not set
+CONFIG_SERIO=y
+CONFIG_SERIO_I8042=y
+CONFIG_SERIO_SERPORT=y
+CONFIG_SERIO_LIBPS2=y
+# CONFIG_SERIO_RAW is not set
+# CONFIG_SERIO_XILINX_XPS_PS2 is not set
+# CONFIG_SERIO_ALTERA_PS2 is not set
+# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
-# CONFIG_VT is not set
+CONFIG_VT=y
+CONFIG_CONSOLE_TRANSLATIONS=y
+CONFIG_VT_CONSOLE=y
+CONFIG_HW_CONSOLE=y
+# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
@@ -885,6 +945,7 @@ CONFIG_SENSORS_LM80=y
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
+# CONFIG_SENSORS_LIS3_I2C is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
@@ -908,7 +969,7 @@ CONFIG_SSB_POSSIBLE=y
CONFIG_MFD_SUPPORT=y
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
-# CONFIG_MFD_SM501 is not set
+CONFIG_MFD_SM501=y
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
@@ -934,14 +995,116 @@ CONFIG_MFD_SUPPORT=y
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
-# CONFIG_FB is not set
+CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+CONFIG_FB_FOREIGN_ENDIAN=y
+CONFIG_FB_BOTH_ENDIAN=y
+# CONFIG_FB_BIG_ENDIAN is not set
+# CONFIG_FB_LITTLE_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_OF is not set
+# CONFIG_FB_VGA16 is not set
+# CONFIG_FB_S1D13XXX is not set
+CONFIG_FB_SM501=y
+# CONFIG_FB_IBM_GXT4500 is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
+
+#
+# Console display driver support
+#
+CONFIG_VGA_CONSOLE=y
+# CONFIG_VGACON_SOFT_SCROLLBACK is not set
+CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+# CONFIG_LOGO is not set
# CONFIG_SOUND is not set
+CONFIG_HID_SUPPORT=y
+CONFIG_HID=y
+# CONFIG_HIDRAW is not set
+
+#
+# USB Input Devices
+#
+CONFIG_USB_HID=y
+# CONFIG_HID_PID is not set
+# CONFIG_USB_HIDDEV is not set
+
+#
+# Special HID drivers
+#
+# CONFIG_HID_3M_PCT is not set
+# CONFIG_HID_A4TECH is not set
+# CONFIG_HID_ACRUX_FF is not set
+# CONFIG_HID_APPLE is not set
+# CONFIG_HID_BELKIN is not set
+# CONFIG_HID_CANDO is not set
+# CONFIG_HID_CHERRY is not set
+# CONFIG_HID_CHICONY is not set
+# CONFIG_HID_CYPRESS is not set
+# CONFIG_HID_DRAGONRISE is not set
+# CONFIG_HID_EGALAX is not set
+# CONFIG_HID_EZKEY is not set
+# CONFIG_HID_KYE is not set
+# CONFIG_HID_UCLOGIC is not set
+# CONFIG_HID_WALTOP is not set
+# CONFIG_HID_GYRATION is not set
+# CONFIG_HID_TWINHAN is not set
+# CONFIG_HID_KENSINGTON is not set
+# CONFIG_HID_LOGITECH is not set
+# CONFIG_HID_MICROSOFT is not set
+# CONFIG_HID_MOSART is not set
+# CONFIG_HID_MONTEREY is not set
+# CONFIG_HID_NTRIG is not set
+# CONFIG_HID_ORTEK is not set
+# CONFIG_HID_PANTHERLORD is not set
+# CONFIG_HID_PETALYNX is not set
+# CONFIG_HID_PICOLCD is not set
+# CONFIG_HID_QUANTA is not set
+# CONFIG_HID_ROCCAT is not set
+# CONFIG_HID_ROCCAT_KONE is not set
+# CONFIG_HID_ROCCAT_PYRA is not set
+# CONFIG_HID_SAMSUNG is not set
+# CONFIG_HID_SONY is not set
+# CONFIG_HID_STANTUM is not set
+# CONFIG_HID_SUNPLUS is not set
+# CONFIG_HID_GREENASIA is not set
+# CONFIG_HID_SMARTJOYPLUS is not set
+# CONFIG_HID_TOPSEED is not set
+# CONFIG_HID_THRUSTMASTER is not set
+# CONFIG_HID_ZEROPLUS is not set
+# CONFIG_HID_ZYDACRON is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
@@ -1007,6 +1170,7 @@ CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
+# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_UAS is not set
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v3] PPC4xx: Adding PCI(E) MSI support
From: Philipp Ittershagen @ 2010-12-04 10:02 UTC (permalink / raw)
To: tmarri; +Cc: linuxppc-dev
In-Reply-To: <1291426393-1429-1-git-send-email-tmarri@apm.com>
Hi,
a few nitpicks here. I don't have any clue about MSI, but I have seen
some code-style related issues.
On 12/04/2010 02:33 AM, tmarri@apm.com wrote:
> +static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +{
> + int err = 0;
> + int int_no = -ENOMEM;
> + unsigned int virq;
> + struct msi_msg msg;
> + struct msi_desc *entry;
> + struct ppc4xx_msi *msi_data = &ppc4xx_msi;
> +
> + list_for_each_entry(entry, &dev->msi_list, list) {
> + int_no = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
> + if(int_no >= 0)
> + break;
> + if(int_no < 0) {
> +
Empty line here not needed.
> + err = int_no;
> + pr_debug("%s: fail allocating msi interrupt\n",
> + __func__);
> + }
> + virq = irq_of_parse_and_map(msi_data->msi_dev, int_no);
> + if (virq == NO_IRQ) {
> + dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
> + msi_bitmap_free_hwirqs(&msi_data->bitmap, int_no, 1);
> + err = -ENOSPC;
> + goto out_free;
> + }
> + msi_data->msi_virqs[int_no] = virq;
> + set_irq_data(virq, (void *)int_no);
> + dev_dbg(&dev->dev, "%s: virq = %d \n", __func__, virq);
> +
> + /* Setup msi address space */
> + msg.address_hi = msi_data->msi_addr_hi;
> + msg.address_lo = msi_data->msi_addr_lo;
> +
> + set_irq_msi(virq, entry);
> + msg.data = int_no;
> + write_msi_msg(virq, &msg);
> + }
> +
> +out_free:
> + return err;
> +}
You don't really need the goto-style here, because you have nothing to
clean up when returning. You could instead return directly and save some
lines, because you don't have to assign err and then use goto all the time.
> +
> +void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
> +{
> + struct msi_desc *entry;
> + struct ppc4xx_msi *msi_data = &ppc4xx_msi;
> +
> + dev_dbg(&dev->dev, "PCIE-MSI: tearing down msi irqs\n");
> +
> + list_for_each_entry(entry, &dev->msi_list, list) {
> + if (entry->irq == NO_IRQ)
> + continue;
> + set_irq_msi(entry->irq, NULL);
> + msi_bitmap_free_hwirqs(&msi_data->bitmap,
> + virq_to_hw(entry->irq), 1);
> + irq_dispose_mapping(entry->irq);
> + }
> +
> + return;
This return is not needed.
> +static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
> + struct resource res, struct ppc4xx_msi *msi)
> +{
> + const u32 *msi_data;
> + const u32 *msi_mask;
> + const u32 *sdr_addr;
> + int err = 0;
> + dma_addr_t msi_phys;
> + void *msi_virt;
> +
> + sdr_addr = of_get_property(dev->dev.of_node, "sdr-base", NULL);
> + if (!sdr_addr)
> + return -1;
> +
> + SDR0_WRITE(sdr_addr, (u64)res.start >> 32); /*HIGH addr */
> + SDR0_WRITE(sdr_addr + 1, res.start & 0xFFFFFFFF); /* Low addr */
> +
> +
> + msi->msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
> + if (msi->msi_dev) {
> + err = -ENODEV;
> + goto error_out;
> + }
> + msi->msi_regs = of_iomap(msi->msi_dev, 0);
> + if (!msi->msi_regs) {
> + dev_err(&dev->dev, "of_iomap problem failed\n");
> + return -ENOMEM;
> + }
You directly return here and in all other bad cases this function
covers, you use the goto-style (which you don't really need here,
because there is no cleanup to do in case of a failure). Better use a
consistent way for returning.
> + msi_data = of_get_property(dev->dev.of_node, "msi-data", NULL);
> + if (!msi_data) {
> + err = -1;
> + goto error_out;
> + }
> +
> + msi_mask = of_get_property(dev->dev.of_node, "msi-mask", NULL);
> + if (!msi_mask) {
> + err = -1;
> + goto error_out;
> + }
> +
> + /* Program MSI Expected data and Mask bits */
> + out_be32(msi->msi_regs + PEIH_MSIED, *msi_data);
> + out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
> +
> + return err;
> +error_out:
> + return err;
> +}
This was already mentioned by Josh Boyer.
> +
> +static int ppc4xx_of_msi_remove(struct platform_device *dev)
> +{
> + struct ppc4xx_msi *msi = dev->dev.platform_data;
> + int i;
> + int virq;
> +
> + for(i = 0; i < NR_MSI_IRQS; i++) {
> + virq = msi->msi_virqs[i];
> + if (virq != NO_IRQ)
> + irq_dispose_mapping(virq);
> + }
> +
> + if (msi->bitmap.bitmap)
> + msi_bitmap_free(&msi->bitmap);
> + iounmap(msi->msi_regs);
> + of_node_put(msi->msi_dev);
> + kfree(msi);
> +
> + return 0;
> +}
> +
> +static int __devinit ppc4xx_msi_probe(struct platform_device *dev,
> + const struct of_device_id *match)
> +{
> + struct ppc4xx_msi *msi;
> + struct resource res;
> + int err = 0;
> +
> + msi = &ppc4xx_msi;/*keep the msi data for further use*/
> +
> + dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
> +
> + msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
> + if (!msi) {
> + dev_err(&dev->dev, "No memory for MSI structure\n");
> + err = -ENOMEM;
> + goto error_out;
> + }
> + dev->dev.platform_data = msi;
> +
[...]
> +
> +error_out:
> + ppc4xx_of_msi_remove(dev);
> + return err;
> +}
If this function fails on allocating memory, you don't have to remove
your device because it was not created and therefore the expected
resources are not available in your *_remove function.
Hope this helps!
Philipp
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gary Thomas @ 2010-12-04 12:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <4CEBD33D.7020603@mlbassoc.com>
On 11/23/2010 07:44 AM, Gary Thomas wrote:
> On 11/22/2010 01:26 PM, Benjamin Herrenschmidt wrote:
>> On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
>>> I have a bit more information on this. I'm pretty sure that the failures
>>> are only happening in my SCSI (SATA actually) code. My board (8347ea)
>>> has
>>> a PCI bus with a SIL SATA controller. This combo works perfectly in
>>> 2.6.28.
>>> In 2.6.32, it will run for a while (possibly quite a while), then
>>> timeout
>>> trying to do a large block write - typically 256 blocks. Once this
>>> timeout
>>> happens, the SIL controller is stuck and accesses to it will eventually
>>> cause the whole system to hang (as above).
>>>
>>> Was there any major change in how PCI or DMA was handled between 2.6.28
>>> and 2.6.32? Given the ephemeral nature of these failures (multiple runs
>>> all eventually fail, but never the same twice), my only hope of
>>> fixing it
>>> will be to have some ideas what might have changed.
>>
>> Maybe the changes you did to the PCI outbound windows are now breaking
>> DMA ? Make sure the outbound and inbound don't overlap for example and
>> that all RAM is reachable for inbound.
>
> Here's what I did to work around this - in my DTS, I set up my PCI as
> ranges = <0x02000000 0x0 0xC4000000 0xC4000000 0x0 0x1C000000
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
> Before, I had it as
> ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
>
> I wasn't sure how to reserve the memory (based on your earlier suggestion),
> so I just narrowed the window. Note that I did not change the PCI hardware
> registers (maybe the FSL code does?), so the outbound window should still
> be the whole 512MB.
>
> If this isn't viable, perhaps you could explain a bit more how to reserve
> such a chunk of memory so that the PCI mappings remain the same.
Any ideas on this? I'm a bit lost as to how to reserve the memory like
you suggested and what I've tried so far has met little success.
Thanks again
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Change in PCI behaviour
From: Benjamin Herrenschmidt @ 2010-12-04 21:07 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CFA38D8.3060209@mlbassoc.com>
On Sat, 2010-12-04 at 05:49 -0700, Gary Thomas wrote:
> On 11/23/2010 07:44 AM, Gary Thomas wrote:
> > On 11/22/2010 01:26 PM, Benjamin Herrenschmidt wrote:
> >> On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
> >>> I have a bit more information on this. I'm pretty sure that the failures
> >>> are only happening in my SCSI (SATA actually) code. My board (8347ea)
> >>> has
> >>> a PCI bus with a SIL SATA controller. This combo works perfectly in
> >>> 2.6.28.
> >>> In 2.6.32, it will run for a while (possibly quite a while), then
> >>> timeout
> >>> trying to do a large block write - typically 256 blocks. Once this
> >>> timeout
> >>> happens, the SIL controller is stuck and accesses to it will eventually
> >>> cause the whole system to hang (as above).
> >>>
> >>> Was there any major change in how PCI or DMA was handled between 2.6.28
> >>> and 2.6.32? Given the ephemeral nature of these failures (multiple runs
> >>> all eventually fail, but never the same twice), my only hope of
> >>> fixing it
> >>> will be to have some ideas what might have changed.
> >>
> >> Maybe the changes you did to the PCI outbound windows are now breaking
> >> DMA ? Make sure the outbound and inbound don't overlap for example and
> >> that all RAM is reachable for inbound.
> >
> > Here's what I did to work around this - in my DTS, I set up my PCI as
> > ranges = <0x02000000 0x0 0xC4000000 0xC4000000 0x0 0x1C000000
> > 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
> > Before, I had it as
> > ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
> > 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
> >
> > I wasn't sure how to reserve the memory (based on your earlier suggestion),
> > so I just narrowed the window. Note that I did not change the PCI hardware
> > registers (maybe the FSL code does?), so the outbound window should still
> > be the whole 512MB.
> >
> > If this isn't viable, perhaps you could explain a bit more how to reserve
> > such a chunk of memory so that the PCI mappings remain the same.
>
> Any ideas on this? I'm a bit lost as to how to reserve the memory like
> you suggested and what I've tried so far has met little success.
>
> Thanks again
>
Look at pcibios_reserve_legacy_regions() in
arch/powerpc/kernel/pci-common.c, it "reserves" the legacy IO and VGA
regions on host bridges. You can make it reserve whatever your
device is allergic too.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-04 21:16 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <1291450906-22445-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 7997 bytes --]
On Sat, Dec 04, 2010 at 09:21:46AM +0100, Heiko Schocher wrote:
> - MPC5200
> - serielle console on PSC 1
serial
> - 128MiB RAM
> - 32MiB NOR Flash
> - FEC Ethernet
> - 2 I2C Busses
> - FPGA on CS3 accessed through mtd-ram
> - ATA
although I am not sure we need those details in the commit log
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> based against 2.6.37-rc4
>
> ./scripts/checkpatch.pl 0001-powerpc-5200-add-support-for-charon-board.patch
> total: 0 errors, 0 warnings, 233 lines checked
>
> 0001-powerpc-5200-add-support-for-charon-board.patch has no obvious style problems and is ready for submission.
>
> arch/powerpc/boot/dts/charon.dts | 226 ++++++++++++++++++++++++++
> arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
> 2 files changed, 227 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/charon.dts
>
> diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts
> new file mode 100644
> index 0000000..768f0cc
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/charon.dts
> @@ -0,0 +1,226 @@
> +/*
> + * TQM5200 board Device Tree Source
Ooops ;) Your board name here, maybe "based on TQM"
> + *
> + * Copyright (C) 2007 Semihalf
> + * Marian Balakowicz <m8@semihalf.com>
> + *
> + * Copyright (C) 2010 DENX Software Engineering GmbH
> + * Heiko Schocher <hs@denx.de>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "anon,charon";
> + compatible = "anon,charon";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&mpc5200_pic>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,5200@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + d-cache-size = <0x4000>; // L1, 16K
> + i-cache-size = <0x4000>; // L1, 16K
> + timebase-frequency = <0>; // from bootloader
> + bus-frequency = <0>; // from bootloader
> + clock-frequency = <0>; // from bootloader
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x08000000>; // 128MB
> + };
> +
> + soc5200@f0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc5200-immr";
> + ranges = <0 0xf0000000 0x0000c000>;
> + reg = <0xf0000000 0x00000100>;
> + bus-frequency = <0>; // from bootloader
> + system-frequency = <0>; // from bootloader
> +
> + cdm@200 {
> + compatible = "fsl,mpc5200-cdm";
> + reg = <0x200 0x38>;
> + };
> +
> + mpc5200_pic: interrupt-controller@500 {
> + // 5200 interrupts are encoded into two levels;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + compatible = "fsl,mpc5200-pic";
> + reg = <0x500 0x80>;
> + };
> +
> + timer@600 { // General Purpose Timer
> + compatible = "fsl,mpc5200-gpt";
> + reg = <0x600 0x10>;
> + interrupts = <1 9 0>;
> + fsl,has-wdt;
> + };
> +
> + can@900 {
> + compatible = "fsl,mpc5200-mscan";
> + interrupts = <2 17 0>;
> + reg = <0x900 0x80>;
> + };
> +
> + can@980 {
> + compatible = "fsl,mpc5200-mscan";
> + interrupts = <2 18 0>;
> + reg = <0x980 0x80>;
> + };
> +
> + gpio_simple: gpio@b00 {
> + compatible = "fsl,mpc5200-gpio";
> + reg = <0xb00 0x40>;
> + interrupts = <1 7 0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + usb@1000 {
> + compatible = "fsl,mpc5200-ohci","ohci-be";
> + reg = <0x1000 0xff>;
> + interrupts = <2 6 0>;
> + };
> +
> + dma-controller@1200 {
> + device_type = "dma-controller";
> + compatible = "fsl,mpc5200-bestcomm";
> + reg = <0x1200 0x80>;
> + interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> + 3 4 0 3 5 0 3 6 0 3 7 0
> + 3 8 0 3 9 0 3 10 0 3 11 0
> + 3 12 0 3 13 0 3 14 0 3 15 0>;
> + };
> +
> + xlb@1f00 {
> + compatible = "fsl,mpc5200-xlb";
> + reg = <0x1f00 0x100>;
> + };
> +
> + serial@2000 { // PSC1
> + compatible = "fsl,mpc5200-psc-uart";
> + reg = <0x2000 0x100>;
> + interrupts = <2 1 0>;
> + };
> +
> + serial@2400 { // PSC3
> + compatible = "fsl,mpc5200-psc-uart";
> + reg = <0x2400 0x100>;
> + interrupts = <2 3 0>;
> + };
> +
> + ethernet@3000 {
> + compatible = "fsl,mpc5200-fec";
> + reg = <0x3000 0x400>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <2 5 0>;
> + fixed-link = <1 1 100 0 0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,mpc5200-mdio";
> + reg = <0x3000 0x400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + };
> +
> + ata@3a00 {
> + compatible = "fsl,mpc5200-ata";
> + reg = <0x3a00 0x100>;
> + interrupts = <2 7 0>;
> + };
> +
> + i2c@3d00 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,mpc5200-i2c","fsl-i2c";
> + reg = <0x3d00 0x40>;
> + interrupts = <2 15 0>;
> + };
> +
> +
> + i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,mpc5200-i2c","fsl-i2c";
> + reg = <0x3d40 0x40>;
> + interrupts = <2 16 0>;
> +
> + dtt@28 {
> + compatible = "national,lm80";
> + reg = <0x28>;
> + };
> +
> + rtc@68 {
> + compatible = "dallas,ds1374";
> + reg = <0x68>;
> + };
> + };
> +
> + sram@8000 {
> + compatible = "fsl,mpc5200-sram";
> + reg = <0x8000 0x4000>;
> + };
> + };
> +
> + localbus {
> + compatible = "fsl,mpc5200-lpb","simple-bus";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = < 0 0 0xfc000000 0x02000000
> + 3 0 0xe8000000 0x00080000>;
> +
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 0x02000000>;
> + bank-width = <4>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> +
> + mram0@3,0 {
> + compatible = "mtd-ram";
> + reg = <3 0x00000 0x80000>;
> + bank-width = <1>;
> + };
> + };
> +
> + pci@f0000d00 {
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> + compatible = "fsl,mpc5200-pci";
> + reg = <0xf0000d00 0x100>;
> + interrupt-map-mask = <0xf800 0 0 7>;
> + interrupt-map = <0xc000 0 0 1 &mpc5200_pic 0 0 3
> + 0xc000 0 0 2 &mpc5200_pic 0 0 3
> + 0xc000 0 0 3 &mpc5200_pic 0 0 3
> + 0xc000 0 0 4 &mpc5200_pic 0 0 3>;
> + clock-frequency = <0>; // From boot loader
> + interrupts = <2 8 0 2 9 0 2 10 0>;
> + bus-range = <0 0>;
> + ranges = <0x42000000 0 0x80000000 0x80000000 0 0x10000000
> + 0x02000000 0 0x90000000 0x90000000 0 0x10000000
> + 0x01000000 0 0x00000000 0xa0000000 0 0x01000000>;
> + };
> +};
> diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
> index d45be5b..d2e0096 100644
> --- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
> @@ -58,6 +58,7 @@ static char *board[] __initdata = {
> "promess,motionpro",
> "schindler,cm5200",
> "tqc,tqm5200",
> + "anon,charon",
Those are sorted alphabetically
> NULL
> };
>
> --
> 1.7.2.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-04 21:17 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <1291450914-22485-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
There shall be only one mpc5200-defconfig. Does the genric one work with your
board?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Make auto-loading of therm_pm72 possible
From: Marc Zyngier @ 2010-12-05 15:05 UTC (permalink / raw)
To: Linux PPC Development
The therm_pm72 driver, used on the PowerMac G5 range, cannot be
auto-loaded, since the driver itself creates both the device node
and the driver instance.
Moving the device node creation to the platform setup code and
adding the necessary MODULE_DEVICE_TABLE() information allows the
driver to be automatically loaded by udev on any semi-modern
distribution.
It "fixes" a major source of problem on G5 machines where the
driver wasn't explicitely loaded by default, and the system
would automatically shutdown under load.
Tested on an Xserve G5.
Signed-off-by: Marc Zyngier <maz@misterjones.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/powermac/setup.c | 9 +++++++++
drivers/macintosh/therm_pm72.c | 30 +++++-------------------------
2 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 9deb274..d5aceb7 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -506,6 +506,15 @@ static int __init pmac_declare_of_platform_devices(void)
of_platform_device_create(np, "smu", NULL);
of_node_put(np);
}
+ np = of_find_node_by_type(NULL, "fcu");
+ if (np == NULL) {
+ /* Some machines have strangely broken device-tree */
+ np = of_find_node_by_path("/u3@0,f8000000/i2c@f8001000/fan@15e");
+ }
+ if (np) {
+ of_platform_device_create(np, "temperature", NULL);
+ of_node_put(np);
+ }
return 0;
}
diff --git a/drivers/macintosh/therm_pm72.c b/drivers/macintosh/therm_pm72.c
index 4454927..2e041fd 100644
--- a/drivers/macintosh/therm_pm72.c
+++ b/drivers/macintosh/therm_pm72.c
@@ -2213,6 +2213,9 @@ static void fcu_lookup_fans(struct device_node *fcu_node)
static int fcu_of_probe(struct platform_device* dev, const struct of_device_id *match)
{
state = state_detached;
+ of_dev = dev;
+
+ dev_info(&dev->dev, "PowerMac G5 Thermal control driver %s\n", VERSION);
/* Lookup the fans in the device tree */
fcu_lookup_fans(dev->dev.of_node);
@@ -2235,6 +2238,7 @@ static const struct of_device_id fcu_match[] =
},
{},
};
+MODULE_DEVICE_TABLE(of, fcu_match);
static struct of_platform_driver fcu_of_platform_driver =
{
@@ -2252,8 +2256,6 @@ static struct of_platform_driver fcu_of_platform_driver =
*/
static int __init therm_pm72_init(void)
{
- struct device_node *np;
-
rackmac = of_machine_is_compatible("RackMac3,1");
if (!of_machine_is_compatible("PowerMac7,2") &&
@@ -2261,34 +2263,12 @@ static int __init therm_pm72_init(void)
!rackmac)
return -ENODEV;
- printk(KERN_INFO "PowerMac G5 Thermal control driver %s\n", VERSION);
-
- np = of_find_node_by_type(NULL, "fcu");
- if (np == NULL) {
- /* Some machines have strangely broken device-tree */
- np = of_find_node_by_path("/u3@0,f8000000/i2c@f8001000/fan@15e");
- if (np == NULL) {
- printk(KERN_ERR "Can't find FCU in device-tree !\n");
- return -ENODEV;
- }
- }
- of_dev = of_platform_device_create(np, "temperature", NULL);
- if (of_dev == NULL) {
- printk(KERN_ERR "Can't register FCU platform device !\n");
- return -ENODEV;
- }
-
- of_register_platform_driver(&fcu_of_platform_driver);
-
- return 0;
+ return of_register_platform_driver(&fcu_of_platform_driver);
}
static void __exit therm_pm72_exit(void)
{
of_unregister_platform_driver(&fcu_of_platform_driver);
-
- if (of_dev)
- of_device_unregister(of_dev);
}
module_init(therm_pm72_init);
--
1.7.2.3
^ permalink raw reply related
* Re: PowerMac G4 (Digital Audio)
From: Johannes Berg @ 2010-12-05 15:16 UTC (permalink / raw)
To: Risto Suominen; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinaCDvnOCy1e1Ca92hZO5UuB-9HKe4rvLg7TUEx@mail.gmail.com>
> Your snd-aoa seems to support PowerMac3,4. Is it really tested?
I used to add only IDs that some people tested, until most things worked
and I wholesale added all of the ones found in Darwin.
> The reason I'm asking: people are having problems with sound on that
> machine. Even snd-powermac didn't function, but I believe these
> patches have helped:
>
> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p15.diff
> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff
These patches are odd -- the first one adds something the second
removes? Am I supposed to look at the combination?
> The problem is that active state is inverted (i.e. 1) compared to
> other machines on inputs that detect a plug (and there is no
> audio-gpio-active-state in the device tree in gpio 15 and gpio16).
> Snd-powermac guessed wrong.
>
> How do you handle these in your code?
Well, there is gpio-feature and gpio-pmf right now. I suspect you can
get things working by adding some overrides to ftr_gpio_init(). I guess
you want something like
get_gpio("keywest-gpio1", NULL,
&lineout_mute_gpio,
&lineout_mute_gpio_activestate);
on the PowerMac4,3, and something else for the headphone ...
But frankly, it's been so long that it's not all making perfect sense to
me right now. If you send me a tarball of /proc/device-tree/ maybe I can
take a look -- just looked at my collection and I don't have that one.
johannes
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 5:29 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012031558.35557.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 5357 bytes --]
On Fri, 2010-12-03 at 15:58 +0100, Guillaume Dargaud wrote:
> > No. of_platform_drivers are more/less obsolete. Normal platform drivers
> > can now be associated with a device-tree node just fine.
>
> OK.
>
> If my dts definition is thus:
> xps_acqui_data_0: xps-acqui-data@c9800000 {
> compatible = "xlnx,xps-acqui-data-3.00.a";
> interrupt-parent = <&xps_intc_0>;
> interrupts = < 0 2 >;
> reg = < 0xc9800000 0x10000 >;
> xlnx,family = "virtex4";
> xlnx,include-dphase-timer = <0x1>;
> xlnx,mplb-awidth = <0x20>;
> xlnx,mplb-clk-period-ps = <0x2710>;
> xlnx,mplb-dwidth = <0x40>;
> xlnx,mplb-native-dwidth = <0x40>;
> xlnx,mplb-p2p = <0x0>;
> xlnx,mplb-smallest-slave = <0x20>;
> } ;
>
> What are the names I need to pass to platform_driver_register and
> platform_device_register_simple ? xps_acqui_data_0, xps-acqui-data or xps-
> acqui-data-3.00.a ?
None of the above :) xps_acqui_data_0 is a label, it is only relevant
within the dts source, ie. other nodes may refer to this node by that
label. But the label string is not useful in Linux. The node name
"xps-acqui-data" is visible in Linux, but is generally not used for
discovery, it's just a name. What you do want to use is the full
compatible value, ie. "xlnx,xps-acqui-data-3.00.a".
> Why is there not a word about the functions platform_*_register in my various
> driver books ? LDD 3rd ed (O'Reilly), Writing LDD (Cooperstein) or LKD
> (Love)... Is it something specific to powerpc and the books are oriented x86 ?
Because they're old dead-tree references, that aren't up to date with
the kernel. The LDD website says "LDD3 is current as of the 2.6.10
kernel", that's 25 kernel versions ago! I'm also not aware of any book
that has information on anything other than x86 drivers.
> What's a good source, besides grepping the kernel to no end ?
Nothing really I'm afraid.
So you have a device, it appears in your device tree, and you want to
write a driver for it.
The first issue is that someone needs to create a device for your node,
it doesn't necessarily happen by default. For many platforms this will
all happen "automagically" as long as the device node that describes
your device appears in the right place, but I'll describe it in full
anyway.
In most cases your device will appear below a node that represents a
bus, eg:
foobus@xyz {
compatible = "vendor,foobus-v1.m.n", "simple-bus";
...
yournode@abc {
...
}
}
If that isn't the case you need to arrange for it somehow [1].
Somewhere there needs to be code to probe that bus and create devices on
it. That is usually done in platform code with of_platform_bus_probe().
If you don't know what platform you're on, you can look at a boot log
for a line saying "Using <blah> machine description", it will be very
early in the log. "blah" is then the name of the platform you're on, and
you should be able to grep for it in arch/powerpc/platforms.
Once you've found the .c file for your platform, there should be a call
somewhere to of_platform_bus_probe(), with a list of ids, and one of
those ids should match the compatible property of your bus node. In a
lot of cases that is just "simple-bus".
To check a device is being created for your device node, you can look
in /sys/devices. The device names don't match 100% with what's in the
device tree, but the name should be there, so in your case:
# find /sys/devices -name '*xps-acqui-data*'
Assuming that is working you can start on the driver side of things. A
rough template is:
static int foo_driver_probe(struct platform_device *device,
const struct of_device_id *device_id)
{
struct device_node *dn = device->dev.of_node;
struct foo_device *foo;
pr_devel("%s: probing %s\n", __func__, dn->full_name);
/* Check you really want to probe this device and everything is OK */
foo = kzalloc(sizeof(*foo));
if (!foo)
return -ENOMEM;
foo->regs = of_iomap(dn, 0);
if (!foo->regs)
goto out;
foo->irq = irq_of_parse_and_map(dn, 0);
if (foo->irq == NO_IRQ)
goto out;
etc.
return 0;
}
static const struct of_device_id foo_device_id[] =
{
{ .compatible = "vendor,foo-device" },
{}
};
static struct platform_driver foo_driver = {
.probe = foo_driver_probe,
.driver = {
.name = "foo-driver",
.owner = THIS_MODULE,
.of_match_table = foo_device_id,
},
};
static int __init foo_driver_init(void)
{
return platform_driver_register(&foo_driver);
}
module_init(foo_driver_init);
I probably missed something there, I haven't compiled it (obviously),
but it's a start. Some of this stuff is in flux, but I think everything
I have above is OK at least for now. Grant might correct me :)
cheers
[1]: One option is to put your device under an existing bus, but only if
that (fairly) accurately represents the hardware topology. You might
need to create a new node representing the bus your device appears on.
You can also manually create the device in C, but that is generally not
the right approach unless the device tree is immutable - ie. comes from
firmware that you don't control.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Jeremy Kerr @ 2010-12-06 6:35 UTC (permalink / raw)
To: linuxppc-dev, michael
In-Reply-To: <1291613340.11896.216.camel@concordia>
Hi Michael,
> So you have a device, it appears in your device tree, and you want to
> write a driver for it.
Nice write up, mind if I steal this for the devicetree.org wiki?
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, 5200: add support for charon board
From: Heiko Schocher @ 2010-12-06 6:29 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101204211644.GC671@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Sat, Dec 04, 2010 at 09:21:46AM +0100, Heiko Schocher wrote:
>> - MPC5200
>> - serielle console on PSC 1
>
> serial
Hups, thanks!
>> - 128MiB RAM
>> - 32MiB NOR Flash
>> - FEC Ethernet
>> - 2 I2C Busses
>> - FPGA on CS3 accessed through mtd-ram
>> - ATA
>
> although I am not sure we need those details in the commit log
Okay, I can remove them.
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> ---
>> based against 2.6.37-rc4
>>
>> ./scripts/checkpatch.pl 0001-powerpc-5200-add-support-for-charon-board.patch
>> total: 0 errors, 0 warnings, 233 lines checked
>>
>> 0001-powerpc-5200-add-support-for-charon-board.patch has no obvious style problems and is ready for submission.
>>
>> arch/powerpc/boot/dts/charon.dts | 226 ++++++++++++++++++++++++++
>> arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
>> 2 files changed, 227 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/charon.dts
>>
>> diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts
>> new file mode 100644
>> index 0000000..768f0cc
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/charon.dts
>> @@ -0,0 +1,226 @@
>> +/*
>> + * TQM5200 board Device Tree Source
>
> Ooops ;) Your board name here, maybe "based on TQM"
Yep, thats right! I rename this to charon, thanks for detecting.
[...]
>> diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> index d45be5b..d2e0096 100644
>> --- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> @@ -58,6 +58,7 @@ static char *board[] __initdata = {
>> "promess,motionpro",
>> "schindler,cm5200",
>> "tqc,tqm5200",
>> + "anon,charon",
>
> Those are sorted alphabetically
Change this!
Thanks for the review,
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-06 6:44 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <4CFC82C3.3090307@denx.de>
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
On Mon, Dec 06, 2010 at 07:29:23AM +0100, Heiko Schocher wrote:
> Thanks for the review,
You're welcome. Oh, just to make sure: It is really a MPC5200 and not a
MPC5200B?
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, 5200: add support for charon board
From: Heiko Schocher @ 2010-12-06 6:55 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101206064444.GA31994@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Mon, Dec 06, 2010 at 07:29:23AM +0100, Heiko Schocher wrote:
>
>> Thanks for the review,
>
> You're welcome. Oh, just to make sure: It is really a MPC5200 and not a
> MPC5200B?
Yep, it is a MPC5200
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 7:30 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101204211734.GD671@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
>
> There shall be only one mpc5200-defconfig. Does the genric one work with your
> board?
Just tried, mpc5200_defconfig works for me, but...
... I miss there the LM81 and RTC DS1374 support ... and in another
patchset from me, I add SM501 support for this board ... also
for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
Just a fast thought (I am not a kconfig expert):
As there is a mpc5200_defconfig, couldn;t we get rid of the board
defconfig(s), and add instead a possibility to store only the changes
against the mpc5200_defconfig in a file? That would save a lot of unneeded
lines, and maintaining would be easier as common 5200 config options
are stored in mpc5200_defconfig ... and a "make board_settings" would do:
- call "make mpc5200_defconfig"
- process differences stored in "board_settings"
(something like menuconfig, just not interactive)
(we could generalize that approach, because I think, all defconfigs
are not easy to maintain, if we say first line is always the defconfig
we call, following lines are options different to that ...)
Example for the charon board "charon_settings" file:
call mpc5200_defconfig // call "make mpc5200_defconfig"
enable SENSORS_LM80 // call something like "make menuconfig -e SENSORS_LM80"
disable FB_RADEON // call something like "make menuconfig -d FB_RADEON"
disable SPI
disable RTC_DRV_DS1307
enable RTC_DRV_DS1374
...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Anatolij Gustschin @ 2010-12-06 8:49 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4CFC911D.4070306@denx.de>
Hello Heiko,
On Mon, 06 Dec 2010 08:30:37 +0100
Heiko Schocher <hs@denx.de> wrote:
> Hello Wolfram,
>
> Wolfram Sang wrote:
> > On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
> >
> > There shall be only one mpc5200-defconfig. Does the genric one work with your
> > board?
>
> Just tried, mpc5200_defconfig works for me, but...
>
> ... I miss there the LM81 and RTC DS1374 support ... and in another
> patchset from me, I add SM501 support for this board ... also
> for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
>
> Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
> Just a fast thought (I am not a kconfig expert):
>
> As there is a mpc5200_defconfig, couldn;t we get rid of the board
> defconfig(s), and add instead a possibility to store only the changes
> against the mpc5200_defconfig in a file? That would save a lot of unneeded
> lines, and maintaining would be easier as common 5200 config options
> are stored in mpc5200_defconfig ... and a "make board_settings" would do:
You can save a reduced config file in ./defconfig by running
"make savedefconfig". This ./defconfig file can also be used as a
board config file in arch/powerpc/configs/52xx/. Look e.g. at the
config files under arch/powerpc/configs/52xx/.
Anatolij
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 9:13 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20101206094925.3dd90271@wker>
Hello Anatolij,
Anatolij Gustschin wrote:
> On Mon, 06 Dec 2010 08:30:37 +0100
> Heiko Schocher <hs@denx.de> wrote:
>
>> Hello Wolfram,
>>
>> Wolfram Sang wrote:
>>> On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
>>>
>>> There shall be only one mpc5200-defconfig. Does the genric one work with your
>>> board?
>> Just tried, mpc5200_defconfig works for me, but...
>>
>> ... I miss there the LM81 and RTC DS1374 support ... and in another
>> patchset from me, I add SM501 support for this board ... also
>> for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
>>
>> Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
>> Just a fast thought (I am not a kconfig expert):
>>
>> As there is a mpc5200_defconfig, couldn;t we get rid of the board
>> defconfig(s), and add instead a possibility to store only the changes
>> against the mpc5200_defconfig in a file? That would save a lot of unneeded
>> lines, and maintaining would be easier as common 5200 config options
>> are stored in mpc5200_defconfig ... and a "make board_settings" would do:
>
> You can save a reduced config file in ./defconfig by running
> "make savedefconfig". This ./defconfig file can also be used as a
> board config file in arch/powerpc/configs/52xx/. Look e.g. at the
> config files under arch/powerpc/configs/52xx/.
Ah, Ok, great.
If such a file is accepted in mainline, I make a v2 post.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-06 9:31 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <4CFCA91C.9030107@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
> If such a file is accepted in mainline, I make a v2 post.
===
commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Mon Jan 21 11:22:22 2008 -0700
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
There is no reason to have separate defconfigs for each mpc5200 board.
Instead, here is a common defconfig that can be used for all supported
platforms.
Merging the defconfigs means there are fewer configuration to test when
compile testing all of arch/powerpc and should make support easier.
Supported boards:
Lite5200(b), Efika, TQM5200, CM5200, MotionPro
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
===
A defconfig which brings the board up is good enough. Specific projects tend to
have specialized configs anyhow.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 9:49 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20101206093148.GA7320@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
>> If such a file is accepted in mainline, I make a v2 post.
>
> ===
>
> commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
> Author: Grant Likely <grant.likely@secretlab.ca>
> Date: Mon Jan 21 11:22:22 2008 -0700
>
> [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
>
> There is no reason to have separate defconfigs for each mpc5200 board.
> Instead, here is a common defconfig that can be used for all supported
> platforms.
>
> Merging the defconfigs means there are fewer configuration to test when
> compile testing all of arch/powerpc and should make support easier.
>
> Supported boards:
> Lite5200(b), Efika, TQM5200, CM5200, MotionPro
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ===
>
> A defconfig which brings the board up is good enough. Specific projects tend to
> have specialized configs anyhow.
Hmm.. applies this also to the DTS?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-06 9:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291613340.11896.216.camel@concordia>
Thank you for the detailed answer. I'm trying to digest it...
> > What's a good source, besides grepping the kernel to no end ?
>
> Nothing really I'm afraid.
8-|
> So you have a device, it appears in your device tree, and you want to
> write a driver for it.
That's the idea. Communication between usermode and the driver is limited to
simple ioctl calls and the driver receives an interrupt when certain data has
been placed in memory blocks by the hardware (like a DMA). Then the user prog
figures out where that latest data buffer is (mmap) and saves it.
> The first issue is that someone needs to create a device for your node,
> it doesn't necessarily happen by default. For many platforms this will
> all happen "automagically" as long as the device node that describes
> your device appears in the right place, but I'll describe it in full
> anyway.
I'm on a minimalist embedded system (buildroot+busybox+uclibc), so I'm pretty
sure I have to do the whole thing. No udev/HAL here.
> In most cases your device will appear below a node that represents a
> bus, eg:
>
> foobus@xyz {
> compatible = "vendor,foobus-v1.m.n", "simple-bus";
> ...
> yournode@abc {
> ...
> }
> }
>
> If that isn't the case you need to arrange for it somehow [1].
Commenting on your [1] here. So should I just add "simple-bus" or does the
VHDL needs to be modified so as to generate this additional bus info ?
I indeed have:
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,virtex405", "xlnx,virtex";
model = "testing";
...
plb: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-
bus";
ranges ;
...
xps_acqui_data_0: xps-acqui-data@c9800000 {
compatible = "xlnx,xps-acqui-data-3.00.a";
...
}
...
}
...
}
> Somewhere there needs to be code to probe that bus and create devices on
> it. That is usually done in platform code with of_platform_bus_probe().
Isn't the of_* code outdated (just been told that on a previous message) ?
Or was it just for of_register_platform_driver ?
> If you don't know what platform you're on, you can look at a boot log
> for a line saying "Using <blah> machine description", it will be very
> early in the log. "blah" is then the name of the platform you're on, and
> you should be able to grep for it in arch/powerpc/platforms.
"Using Xilinx Virtex machine description"
> Once you've found the .c file for your platform, there should be a call
> somewhere to of_platform_bus_probe(), with a list of ids, and one of
> those ids should match the compatible property of your bus node. In a
> lot of cases that is just "simple-bus".
That'd be:
arch/powerpc/platforms/40x/virtex.c:51: .name = "Xilinx Virtex",
and
arch/powerpc/platforms/40x/virtex.c:21: { .compatible = "simple-bus", },
No match for simple-bus of acqui-data in dmesg.
> To check a device is being created for your device node, you can look
> in /sys/devices. The device names don't match 100% with what's in the
> device tree, but the name should be there, so in your case:
>
> # find /sys/devices -name '*xps-acqui-data*'
Indeed:
# ll /sys/devices/plb.0/c9800000.xps-acqui-data
-r--r--r-- 1 root root 4.0K Dec 6 09:47 devspec
-r--r--r-- 1 root root 4.0K Dec 6 09:47 modalias
-r--r--r-- 1 root root 4.0K Dec 6 09:47 name
lrwxrwxrwx 1 root root 0 Dec 6 09:47 subsystem ->
../../../bus/of_platform/
-rw-r--r-- 1 root root 4.0K Dec 6 09:47 uevent
So that's created on boot, right ?
> [...code snipped...]
I still need a platform_device_register() after your sample init, right ?
I'll get on to adapting your sample code now. Thanks a lot.
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-06 10:01 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <4CFCB195.8000306@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
> Wolfram Sang wrote:
> > On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
> >> If such a file is accepted in mainline, I make a v2 post.
> >
> > ===
> >
> > commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
> > Author: Grant Likely <grant.likely@secretlab.ca>
> > Date: Mon Jan 21 11:22:22 2008 -0700
> >
> > [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
> >
> > There is no reason to have separate defconfigs for each mpc5200 board.
> > Instead, here is a common defconfig that can be used for all supported
> > platforms.
> >
> > Merging the defconfigs means there are fewer configuration to test when
> > compile testing all of arch/powerpc and should make support easier.
> >
> > Supported boards:
> > Lite5200(b), Efika, TQM5200, CM5200, MotionPro
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > ===
> >
> > A defconfig which brings the board up is good enough. Specific projects tend to
> > have specialized configs anyhow.
>
> Hmm.. applies this also to the DTS?
How should that work? :) There is one kernel with all needed options
(the optional ones being modules) and the DTS selects what is needed.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 10:25 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20101206100116.GB7320@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
>> Wolfram Sang wrote:
>>> On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
>>>> If such a file is accepted in mainline, I make a v2 post.
>>> ===
>>>
>>> commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
>>> Author: Grant Likely <grant.likely@secretlab.ca>
>>> Date: Mon Jan 21 11:22:22 2008 -0700
>>>
>>> [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
>>>
>>> There is no reason to have separate defconfigs for each mpc5200 board.
>>> Instead, here is a common defconfig that can be used for all supported
>>> platforms.
>>>
>>> Merging the defconfigs means there are fewer configuration to test when
>>> compile testing all of arch/powerpc and should make support easier.
>>>
>>> Supported boards:
>>> Lite5200(b), Efika, TQM5200, CM5200, MotionPro
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> ===
>>>
>>> A defconfig which brings the board up is good enough. Specific projects tend to
>>> have specialized configs anyhow.
>> Hmm.. applies this also to the DTS?
>
> How should that work? :) There is one kernel with all needed options
> (the optional ones being modules) and the DTS selects what is needed.
Ok, so I post a v2 without defconfig patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 11:56 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <201012061435.07393.jk@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
On Mon, 2010-12-06 at 14:35 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
>
> Nice write up, mind if I steal this for the devicetree.org wiki?
Sure thing, feel free to correct any mistakes too ;D
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 12:07 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012061058.37612.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 5284 bytes --]
On Mon, 2010-12-06 at 10:58 +0100, Guillaume Dargaud wrote:
> Thank you for the detailed answer. I'm trying to digest it...
>
> > > What's a good source, besides grepping the kernel to no end ?
> >
> > Nothing really I'm afraid.
> 8-|
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
> That's the idea. Communication between usermode and the driver is limited to
> simple ioctl calls and the driver receives an interrupt when certain data has
> been placed in memory blocks by the hardware (like a DMA). Then the user prog
> figures out where that latest data buffer is (mmap) and saves it.
OK, that should be all pretty straight forward, and covered by the
material in LDD and similar references. You just need to get your device
probed.
> > The first issue is that someone needs to create a device for your node,
> > it doesn't necessarily happen by default. For many platforms this will
> > all happen "automagically" as long as the device node that describes
> > your device appears in the right place, but I'll describe it in full
> > anyway.
>
> I'm on a minimalist embedded system (buildroot+busybox+uclibc), so I'm pretty
> sure I have to do the whole thing. No udev/HAL here.
That's another problem. The device I'm talking about here is just the
minimal struct in the kernel that you need in order for your driver to
probe against it. Once your driver has matched against a device then you
(might) need to worry about exposing a device to userspace in /dev.
> > In most cases your device will appear below a node that represents a
> > bus, eg:
> >
> > foobus@xyz {
> > compatible = "vendor,foobus-v1.m.n", "simple-bus";
> > ...
> > yournode@abc {
> > ...
> > }
> > }
> >
> > If that isn't the case you need to arrange for it somehow [1].
>
> Commenting on your [1] here. So should I just add "simple-bus" or does the
> VHDL needs to be modified so as to generate this additional bus info ?
Doesn't look like it:
> I indeed have:
>
> /dts-v1/;
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,virtex405", "xlnx,virtex";
> model = "testing";
> ...
> plb: plb@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-bus";
> ranges ;
> ...
> xps_acqui_data_0: xps-acqui-data@c9800000 {
> compatible = "xlnx,xps-acqui-data-3.00.a";
> ...
> }
> ...
> }
> ...
> }
That looks good.
> > Somewhere there needs to be code to probe that bus and create devices on
> > it. That is usually done in platform code with of_platform_bus_probe().
>
> Isn't the of_* code outdated (just been told that on a previous message) ?
> Or was it just for of_register_platform_driver ?
No it's just that platform_drivers are now able to do all the things an
of_platform_driver can do, so new code should just use platform_driver.
I'm not sure if of_platform_bus_probe() will go away eventually, but for
now it is the only way to achieve what you need.
> > If you don't know what platform you're on, you can look at a boot log
> > for a line saying "Using <blah> machine description", it will be very
> > early in the log. "blah" is then the name of the platform you're on, and
> > you should be able to grep for it in arch/powerpc/platforms.
>
> "Using Xilinx Virtex machine description"
Cool.
> > Once you've found the .c file for your platform, there should be a call
> > somewhere to of_platform_bus_probe(), with a list of ids, and one of
> > those ids should match the compatible property of your bus node. In a
> > lot of cases that is just "simple-bus".
>
> That'd be:
> arch/powerpc/platforms/40x/virtex.c:51: .name = "Xilinx Virtex",
> and
> arch/powerpc/platforms/40x/virtex.c:21: { .compatible = "simple-bus", },
Perfect.
> No match for simple-bus of acqui-data in dmesg.
That's normal, if the kernel printed out every device it found you'd
drown in messages. If you want to you can put a printk in
of_platform_device_create() and you should see it.
> > To check a device is being created for your device node, you can look
> > in /sys/devices. The device names don't match 100% with what's in the
> > device tree, but the name should be there, so in your case:
> >
> > # find /sys/devices -name '*xps-acqui-data*'
>
> Indeed:
> # ll /sys/devices/plb.0/c9800000.xps-acqui-data
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 devspec
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 modalias
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 name
> lrwxrwxrwx 1 root root 0 Dec 6 09:47 subsystem -> ../../../bus/of_platform/
> -rw-r--r-- 1 root root 4.0K Dec 6 09:47 uevent
>
> So that's created on boot, right ?
Yep, so that is all working fine. You just need to write a driver that
will match against that device.
> > [...code snipped...]
>
> I still need a platform_device_register() after your sample init, right ?
I had one in there already, in foo_driver_init(), didn't I?
> I'll get on to adapting your sample code now. Thanks a lot.
No worries.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: Getting the IRQ number (Was: Basic driver devel questions ?)
From: David Laight @ 2010-12-06 12:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201012061058.37612.dargaud@lpsc.in2p3.fr>
=20
> That's the idea. Communication between usermode and the driver is
limited to=20
> simple ioctl calls and the driver receives an interrupt when certain
data has=20
> been placed in memory blocks by the hardware (like a DMA).=20
> Then the user prog figures out where that latest data buffer is (mmap)
and saves it.=20
I've used pread() and pwrite() to directly copy data to/from a devices
PCI memory space.
The driver just verifies the offset and calls copy_to/from_user() [1].
High offsets can be used to access driver specific data.
The userspace code for pread/write is less painful than using ioctl()
for everything.
This also lets you dump the device memory space with hexdump.
I also made the device interrupt generate POLLIN (this needs a bit of
care since the interrupt can arrive before poll() is called).
David
[1] I actually had to use the PCIe dma controller to get adequate
throughput.
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-06 14:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291637228.21242.14.camel@concordia>
Hello all,
> OK, that should be all pretty straight forward, and covered by the
> material in LDD and similar references. You just need to get your device
> probed.
I'm not sure what you mean with that term: simply identifying that the device
works using device specific code ?
I've looked at several *_probe functions from other drivers and they are all
completely different with no common code...
Or do you mean calling of_platform_bus_probe() ? What does that function do ?
> No it's just that platform_drivers are now able to do all the things an
> of_platform_driver can do, so new code should just use platform_driver.
>
> I'm not sure if of_platform_bus_probe() will go away eventually, but for
> now it is the only way to achieve what you need.
I assume the kernel needs to be compiled with CONFIG_OF.
...hmm I had to "git pull" in order for this to compile your snippet. That's
really recent! Unfortunately i need to reflash my device with the new kernel
before i can begin testing my module.
When I try to compile your (adapted) snippet, I got this minor problems:
.probe = foo_driver_probe,
^ warning: initialization from incompatible pointer type
Shouldn't foo_driver_probe be:
static int foo_driver_probe(struct platform_device *pdev)
instead of:
static int foo_driver_probe(struct platform_device *device,
const struct of_device_id *device_id)
Also:
struct foo_device *foo;
That's where I put my own content, right ?
And needs to be kfreed in a foo_driver_remove() function, right ?
> > I still need a platform_device_register() after your sample init, right ?
>
> I had one in there already, in foo_driver_init(), didn't I?
You had platform_driver_register(), not that I'm all clear yet on the
distinction...
Another question: I just spent 10 minutes trying to find where "struct device"
was defined. (ack-)grep was absolutely no use. Isn't there a way to cross-
reference my own kernel, the way I've compiled it ?
--
Guillaume Dargaud
http://www.gdargaud.net/Climbing/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox